简介这份JDK 1.8.0_231 x64 Windows免安装包面向仍要维护Java 8旧项目、承担教学实验或在多台Windows电脑间切换开发环境的程序员与运维人员以免安装的便携形态减少部署环节适合离线机器、机房统一环境和临时调试场景。包内共1469个文件以705个jar类库、228个xml配置为主兼有dll、exe等本地组件以及properties、html等说明文档7z压缩包约115.49MB。目录中既有bin命令行工具、jre运行环境也有include本地接口头文件和lib类库能够支撑Java程序编译、运行、打包及JNI相关开发并保留release版本信息、许可证和第三方许可说明方便核对版本构成与合规边界。已有1033人学习下载适合需要旧系统兼容、课程演示或便携式Java 8工具链的读者取用。对于需要复现旧版运行结果、排查兼容性问题或制作便携开发盘的团队这套目录结构保留了较完整的工具链与运行库可减少重复配置与版本漂移也便于在受限权限的电脑上开展编码、测试和问题定位。1. 免安装 JDK 8u231 到底解决什么问题接手一台不能随便装软件的内网机器或者本地要同时跑三个锁死在不同 JDK 版本上的老项目时JDK 1.8.0_231 的 x64 WIN 免安装版本基本是最省事的那条路。它就是一个 zip 包解压到任意目录、配好环境变量就能编译运行不写注册表、不进「程序和功能」、不覆盖机器上已有的安装版不用了直接删目录没有残留也留得下后悔药。8u231 这个版本号在老项目里出现频率很高很多构建脚本和依赖矩阵都卡在 8u 这条线上而 x64 是现在 Windows 的默认目标平台。适合的人群很明确需要多版本并存的后端开发、要在一台机器上验证不同 JDK 行为的测试、以及没有管理员权限但必须把服务跑起来的实施人员。2. 解压位置和目录结构决定了后面一半的麻烦拿到 zip 包之后别急着双击解压到桌面。免安装版本最大的优势是「位置自由」但最大的坑也恰恰来自位置自由——装错地方后面环境变量、脚本、IDE 报的错会一个接一个而且每个错看起来都跟 JDK 无关。2.1 为什么 Program Files 和带空格的路径是第一道坎C:\Program Files\Java\jdk1.8.0_231这种路径有两个问题。一是权限Program Files 下的写操作默认需要提权JDK 本体运行不需要写文件但keytool改cacerts、某些 IDE 在jre\lib下生成临时文件、老版本的 JNA 释放 dll 到临时目录时都会因为权限不足失败报错信息往往是Access is denied或者一个和权限毫无关联的UnsatisfiedLinkError。二是空格。JAVA_HOME 本身加引号能扛住但下游一堆脚本不加引号Ant 的build.xml里${java.home}/bin/java拼出来就是断的某些-Djava.library.path参数在批处理里被空格切成了两段Tomcat 的setclasspath.bat在老版本里对带空格的 JAVA_HOME 处理也不干净。这类问题的恶心之处在于它不在 JDK 层报错而是在业务启动到一半的时候炸出来。我一般固定用短、纯 ASCII、无空格的路径比如D:\runtime\jdk1.8.0_231。盘符不重要重要的是从根到末级目录全是英文和数字长度控制在 60 字符以内。另外提醒一句别解压到C:\Users\张三\Desktop这种带中文的路径部分老工具用 ANSI 代码页读路径中文会变成问号然后告诉你「系统找不到指定的路径」。2.2 解压完先认清目录bin、jre、lib、db 各管什么免安装版解压出来的结构和安装版完全一致很多人用了几年也没打开看过出问题时不知道去哪儿找东西。下表是我实际排查时最常翻的几个位置目录/文件内容什么时候会碰它bin\java.exe、javac.exe、jar.exe、keytool.exe、jvisualvm.exe、jconsole.exe配 PATH、导证书、看堆和线程jre\bin\server\jvm.dll真正的虚拟机实现报「no jvm.dll」时确认它是否存在jre\lib\rt.jar8 的核心类库排查NoClassDefFoundError时确认类在不在jre\lib\security\cacerts默认信任库内网 HTTPS 握手失败时导入自签证书lib\tools.jar编译器、javadoc 等工具类老项目显式依赖它编译 JSPdb\内置的 Derby 数据库基本用不到可以留着不管include\JNI 头文件jni.h编译本地库时用src.zip标准库源码IDE 里点进 JDK 源码看实现一个容易误解的点8u231 的 zip 包里jre是内嵌在 JDK 目录下的子目录不需要再单独装一个 JRE。免安装版和安装版的区别只在「有没有写注册表和开始菜单」二进制内容是一样的。2.3 用 PowerShell 解压并做一次完整性校验别再手动右键解压了尤其包是从内网文件服务器拷过来的传输截断的概率比想象中高。先用哈希确认包是完整的再解压最后不依赖任何环境变量直接跑一次java -version这是最快的冒烟测试。# 1. 先算 zip 包哈希和归档页公布的 SHA256 逐位比对 Get-FileHash -Path .\jdk-8u231-windows-x64.zip -Algorithm SHA256 | Format-List Algorithm, Hash, Path # 2. 建目标目录路径自己换成短路径、纯 ASCII New-Item -ItemType Directory -Force -Path D:\runtime\jdk1.8.0_231 | Out-Null # 3. 解压。Win10 1803 以后自带 bsdtar比 Expand-Archive 快很多 tar -xf .\jdk-8u231-windows-x64.zip -C D:\runtime\jdk1.8.0_231 # 4. 关键文件存在性检查缺一个就说明包不对或解压中断 $root D:\runtime\jdk1.8.0_231 bin\java.exe,bin\javac.exe,jre\bin\server\jvm.dll,jre\lib\rt.jar | ForEach-Object { $p Join-Path $root $_ {0,-32} {1} -f $_, (Test-Path $p) } # 5. 不配环境变量直接用绝对路径跑一次 $root\bin\java.exe -version逻辑说明第 1 步的哈希比对是唯一能确认「包没被截断或替换」的手段归档页一般会给出 SHA256逐位对别看前八位觉得像就放过。第 3 步用tar而不是Expand-Archive原因是后者在几千个小文件上会慢到让人怀疑人生而tar -xf对 zip 格式同样支持解压速度差好几倍这是实打实的血泪经验。第 5 步刻意不配环境变量因为这一步要验证的是「解压出来的二进制本身能不能跑」如果此时就报错那问题在包或者路径和环境变量无关能省掉一轮排查。参数说明-C指定解压目标目录必须事先存在-Algorithm支持 SHA1/SHA256/SHA512用归档页给的那个算法Format-List是为了让长哈希不被控制台宽度截断。如果你的机器上没有tar很老的 Win10 或者 Server 2012退回Expand-Archive -Path ... -DestinationPath ... -Force只是慢。跑完第 5 步屏幕上应该出现三行输出java version 1.8.0_231、Java(TM) SE Runtime Environment、Java HotSpot(TM) 64-Bit Server VM。第三行里的64-Bit是确认 x64 包没拿错的关键32 位包里这一行写的是Client VM。这一步过了才值得往下配环境变量。3. 环境变量三件套JAVA_HOME、PATH、CLASSPATH 的最小组合免安装版相比安装版缺的就是「自动帮你配环境变量」这一步。手工配不是把三个变量都填满就行恰恰相反配多了比配少更容易出问题。3.1 JAVA_HOME 指向解压根目录不是 bin这是新手最高频的错误把 JAVA_HOME 写成D:\runtime\jdk1.8.0_231\bin。JAVA_HOME 的语义是「JDK 的安装根目录」下游程序全是按这个约定拼路径的——Tomcat 拼%JAVA_HOME%\bin\java.exeMaven 拼%JAVA_HOME%\bin\javac.exe部分老工具还会去%JAVA_HOME%\lib\tools.jar找类。你指到 bin拼出来就变成...\bin\bin\java.exe然后报「系统找不到指定的文件」。现象是java -version单独跑没问题一放到 Tomcat 里就起不来很多人会误以为是 Tomcat 的问题。正确写法rem 系统级需要管理员权限的 cmd所有用户和服务都能读到 setx JAVA_HOME D:\runtime\jdk1.8.0_231 /M rem 或者用户级只影响当前登录账户免安装版推荐这个不污染他人 setx JAVA_HOME D:\runtime\jdk1.8.0_231/M表示写入系统变量不加就是用户变量。区别在权限和作用域系统变量对所有账户和以服务方式启动的进程可见用户变量只在当前账户的会话里可见。这一点在第 5 章会作为独立的坑展开。3.2 PATH 的顺序决定了 where java 指向谁PATH 里加%JAVA_HOME%\bin但加在哪个位置很关键。Windows 查找可执行文件的顺序是从 PATH 前段往后扫先命中先返回。如果机器上曾经装过安装版 JDKC:\Windows\System32或者C:\ProgramData\Oracle\Java\javapath里很可能还躺着一个java.exe而系统 PATH 在拼接时排在用户 PATH 前面结果就是你明明配了新 JDKjava -version出来的还是老版本。稳妥做法是把%JAVA_HOME%\bin放在 PATH 最前面。图形界面里「编辑环境变量」窗口支持上移命令行里则要格外小心——setx PATH会整体覆盖 PATH拼错一个字符就把整条 PATH 清空这是新手最容易踩的坑之一。安全写法是用 PowerShell 读出当前值再拼接# 读用户级 PATH不读系统级避免误伤 $old [Environment]::GetEnvironmentVariable(Path, User) $bin %JAVA_HOME%\bin # 已经存在就不重复加避免 PATH 越来越长 if ($old -notlike *$bin*) { $new if ([string]::IsNullOrEmpty($old)) { $bin } else { $bin;$old } [Environment]::SetEnvironmentVariable(Path, $new, User) Write-Host PATH updated: $new } else { Write-Host already present, skip }逻辑说明GetEnvironmentVariable的第二个参数User明确读用户级不碰系统级降低误伤面。判断-notlike是为了幂等脚本重复执行不会把 PATH 撑爆——PATH 超过 2047 字符后部分老程序会开始丢条目。注意%JAVA_HOME%在这个字符串里没有被展开是故意保留的PATH 里存的是待展开的变量引用实际查找时才展开这样后面切换 JAVA_HOME 时 PATH 不用跟着改。参数说明[Environment]::SetEnvironmentVariable的第三个参数取值是User、Machine、Process分别对应用户级、系统级、当前进程。改系统级必须用管理员权限启动 PowerShell否则抛SecurityException。3.3 CLASSPATH 能不设就不设很多老教程会教你配CLASSPATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。这个习惯来自 JDK 1.4 时代在 8u231 上纯属负担甚至会引发故障。原因有两层第一一旦显式设了 CLASSPATHJava 就不再使用默认的当前目录.你javac编译出来的 class 明明在眼前java MyClass还是报ClassNotFoundException。第二tools.jar只在编译 JSP 等少数场景下需要显式引用现代构建工具自己会处理手工塞进环境变量反而会引入版本冲突。所以 CLASSPATH 这一项我的建议是不设。如果环境里已经被前人手贱设过了用setx CLASSPATH 清空或者干脆删掉这个变量。3.4 三步验证java -version、javac -version、where java配完之后必须新开一个 cmd 窗口老窗口读的还是旧环境。然后依次跑三条where java java -version javac -versionwhere java的作用被严重低估。它把 PATH 里所有叫java.exe的路径全部列出来第一行就是实际会被执行的那个。如果第一行不是你新配的路径后面两条命令的输出再对也没意义——它们跑的是别的 JDK。java -version和javac -version必须都跑而且必须都是1.8.0_231。只跑前者是最常见的验证失误java来自 PATHjavac也来自 PATH理论上同源但机器上如果有安装版残留或者 PATH 里有多个 JDK 的 bin完全可能出现java是 8u231、javac是 11 的组合编译期报的错会非常诡异。4. 一台机器放三个 JDK用目录联接做秒级切换免安装版真正的价值在多版本场景。安装版一次只能装一个换版本要卸载重装免安装版可以在一台机器上并排放五个版本切换成本接近零。关键是别把环境变量改来改去。4.1 JAVA_HOME 指到一个「指针目录」思路很简单实际版本目录按版本号命名另建一个固定的「指针目录」让 JAVA_HOME 永远指向指针目录切换时只改指针的指向环境变量一个字都不动。D:\runtime\ ├── jdk1.8.0_231\ - 实际解压目录 ├── jdk-11.0.x\ - 另一个版本 └── current\ - 指针目录JAVA_HOME 指向这里current不是真的目录是一个目录联接junction指向某个实际版本。JAVA_HOME 设成D:\runtime\currentPATH 设成%JAVA_HOME%\bin。切换版本时删掉联接重建一个环境变量纹丝不动已经打开的 IDE 和终端只要重启进程就能读到新版本。4.2 junction 与符号链接为什么选 /JWindows 上做目录重定向有两个命令mklink /J目录联接和mklink /D目录符号链接。区别在于/D需要管理员权限或开发者模式/J普通用户就能建/D支持跨机器指向网络路径/J只支持本地卷删除方式也不同——/J用rd删用del删不掉。免安装 JDK 的场景下/J完全够用而且不需要提权这一点对没有管理员权限的实施人员很关键。注意联接创建之后资源管理器里看起来就是一个带快捷方式小箭头的普通文件夹但用dir /AL能看到它的真实类型。4.3 setjdk.bat一条命令切版本把下面这段存成setjdk.bat放在 PATH 能扫到的目录里以后切版本就是setjdk 11一条命令的事。echo off setlocal enabledelayedexpansion rem 用法: setjdk 8 或者 setjdk 11 set RTD:\runtime set LINK%RT%\current set TARGET%RT%\jdk%1 rem 允许传 1.8.0_231 这种完整目录名也可以只传主版本号 if not exist %TARGET% ( for /d %%D in (%RT%\jdk%1*) do set TARGET%%D ) if not exist %TARGET% ( echo [ERROR] no matching jdk under %RT% for %1 exit /b 1 ) rem 删旧的联接。注意用 rd 而不是 del且不能加 /s if exist %LINK% rd %LINK% if errorlevel 1 ( echo [ERROR] cannot remove %LINK%, close programs using it exit /b 1 ) mklink /J %LINK% %TARGET% nul if errorlevel 1 ( echo [ERROR] mklink failed exit /b 1 ) echo [OK] current -^ %TARGET% %LINK%\bin\java.exe -version逻辑说明先按主版本号精确匹配目录匹配不到再用通配符jdk%1*找第一个前缀匹配的目录这样setjdk 8和setjdk 1.8.0_231都能用。删除联接时必须用rd而且不能带/s——带了/s会连目标目录里的真实文件一起删掉这是能让人当场心梗的操作务必记牢。最后的java -version是自检切换完立刻确认指向对不对。参数说明%1是第一个命令行参数。enabledelayedexpansion是为在for循环里给变量赋值不加的话set在循环体内不生效。nul屏蔽mklink的提示输出让结果更干净。一个限制要提前知道如果某个 IDE 或服务正持有current目录下的文件句柄rd会失败。所以切换前先把用 JDK 的进程关掉报错信息里那句close programs using it就是提醒你这个。4.4 IDE 和构建工具里单独钉版本不是所有场景都适合动全局 JAVA_HOME。同时开三个项目、每个项目锁不同 JDK 的时候全局切换会互相打架。这时候让 IDE 单独指定就行主流 IDE 的项目结构设置里都能选 JDK指向具体的D:\runtime\jdk1.8.0_231目录构建工具侧再配一次JAVA_HOME覆盖Maven 的mvnw、Gradle 的org.gradle.java.home。原则是全局 JAVA_HOME 定一个基准版本通常是最老的那个项目级配置覆盖具体版本。别让全局变量成为唯一真相否则换个项目就得改一次环境迟早改出事故。5. 避坑免安装 JDK 在 Windows 上翻车的 5 个现场5.1 java 能跑javac 却是另一个版本现象java -version显示 1.8.0_231javac -version显示 11.0.x 或者 17.0.x编译出来的 class 版本号对不上运行时报UnsupportedClassVersionError。原因PATH 里存在多个 JDK 的 bin 目录java.exe和javac.exe分别命中了不同的目录。常见于装过安装版又解压了免安装版的机器或者 IDE 自带的 JRE 被加进了 PATH。解决先where java和where javac分别看全部命中项把非目标 JDK 的 bin 从 PATH 里删掉或者把%JAVA_HOME%\bin提到最前。删完必须新开窗口验证老窗口的环境变量是快照不会跟着变。5.2 路径带中文或空格jar 起不来现象java -jar启动时报Error: Could not find or load main class或者日志里出现乱码路径用 IDE 点运行却一切正常。原因IDE 会用引号包裹路径手写脚本往往不加引号另外部分老工具用系统 ANSI 代码页解析路径中文直接被替换成问号。解决把 JDK 和 jar 都挪到纯 ASCII 短路径下。确实没法挪的脚本里所有路径变量一律加双引号%JAVA_HOME%\bin\java.exe -jar D:\app\demo.jar这种写法不要省。5.3 依赖注册表探测的工具找不到 JDK现象命令行一切正常但某个安装程序、老版本 IDE 或者构建工具提示「No JDK found」让你去指定路径。原因免安装版不写注册表而部分工具是靠读HKLM\SOFTWARE\JavaSoft\Java Development Kit下的版本来发现 JDK 的。这是免安装方案固有的边界不是配置错误。解决优先在工具自己的设置里手动指定 JDK 路径这是最干净的做法。实在没有这个选项才考虑用安装版覆盖或者手工补注册表项——后者不建议容易和后续安装的其他版本打架。5.4 服务账户读不到用户级环境变量现象命令行里java -version正常把同一个应用注册成 Windows 服务后起不来日志提示找不到 java 或者版本不对。原因服务默认以LocalSystem账户运行读的是系统级环境变量看不到你给当前用户配的 JAVA_HOME 和 PATH。解决把 JAVA_HOME 配到系统级setx ... /M需要管理员或者在服务的启动脚本里显式写死绝对路径D:\runtime\jdk1.8.0_231\bin\java.exe不依赖任何环境变量。后者更稳服务场景我一般直接用绝对路径。5.5 控制台中文乱码与 file.encoding现象应用日志里的中文变成问号或方块System.getProperty(file.encoding)返回GBK和预期不符。原因8u231 在中文 Windows 上默认file.encoding跟随系统代码页GBK而很多应用内部按 UTF-8 处理字符串编码不一致就乱码。解决启动参数加-Dfile.encodingUTF-8同时把控制台代码页切到 65001chcp 65001。注意这个参数要放在-jar之前放在 jar 后面会被当成程序参数传给 main 方法完全不生效——这个顺序错误我见过不止一次。6. 把 8u231 用稳内存参数与启动脚本模板最后说几个能让这套东西长期跑下去的手上功夫。8u231 是 8 系列永久代已经被元空间取代所以-XX:PermSize这类参数写了也白写控制台会给你一句ignoring option PermSize; support was removed in 8.0然后继续跑——很多人以为调了其实一直被忽略。真正该调的是这几个参数作用常用取值备注-Xms/-Xmx堆初始/最大值相等如-Xms2g -Xmx2g设成相等避免运行期扩容抖动-XX:MetaspaceSize元空间初始阈值256m触发首次 Full GC 的门槛-XX:MaxMetaspaceSize元空间上限512m不设理论上可无限涨容器里必须设-Dfile.encodingUTF-8默认字符集固定值必须放在-jar之前-Duser.timezoneGMT08:00时区按需服务器时区不对时用来兜底启动脚本我习惯写成这样参数集中在一处改的时候不用翻整个文件echo off setlocal set JAVA_HOMED:\runtime\jdk1.8.0_231 set APP_JARD:\app\demo.jar set LOG_DIRD:\app\logs rem 堆按物理内存的 50%~60% 给这里写死方便复现 set JAVA_OPTS-Xms2g -Xmx2g -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m set JAVA_OPTS%JAVA_OPTS% -Dfile.encodingUTF-8 -Duser.timezoneGMT08:00 set JAVA_OPTS%JAVA_OPTS% -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath%LOG_DIR% rem 注意引号路径有空格时全靠它别省 %JAVA_HOME%\bin\java.exe %JAVA_OPTS% -jar %APP_JAR% %LOG_DIR%\stdout.log 21HeapDumpOnOutOfMemoryError是我强烈建议加的一项OOM 的时候没有堆转储事后排查基本等于看黑匣子。转储文件可能很大HeapDumpPath指向的盘要留够空间。另一个习惯是所有-D开头的系统属性都放在-jar前面jar 后面只放业务参数这条规则写进团队脚本模板里能省掉大量「参数为什么不生效」的追问。最后留个自查习惯每换一台机器部署完免安装 JDK我都会跑一遍三条命令——where java、java -version、javac -version三条输出对齐了才算配完。这个动作花不到十秒但能挡掉后面八成「环境不对」的扯皮。希望帮到你。本文还有配套的精品资源点击获取