JDK 11压缩免安装版Windows配置指南：环境变量与多版本共存

简介JDK11在Windows 64位平台上的压缩免安装版面向Java开发者、运维人员以及需要在无管理员权限环境下快速搭建Java开发或运行环境的用户省去传统安装流程解压配置JAVA_HOME与PATH即可直接使用。资源共423个文件压缩包约171.44MB包含83个dll动态库、72个jmod模块文件、40个exe命令行工具、安全证书、策略配置、源码和release信息等覆盖运行库、模块系统、工具链与安全策略便于按需查看JDK内部组成。作为长期支持版本JDK11带来了模块化系统、HTTP Client API、文本块、G1/ZGC垃圾收集器增强等特性本包对这些特性所需的模块与配置文件均完整保留适合桌面开发、学习新语法或临时环境调试。目前已有1825人学习下载对于希望快速获得完整JDK11免安装环境并深入理解其目录结构的读者是一份可直接部署落地的实用资源。 不知道还有没有人记得JDK 11 是 Oracle 在 2018 年 9 月发布的长期支持版本直到现在很多中小公司、传统 IT 系统的生产环境依然跑在 JDK 8 或 JDK 11 上。之前在一个新项目上需要本地快速搭一套 JDK 11 环境当时图省事用了 exe 安装包点完一轮向导后以为万事大吉结果过了两周因为要切多个 JDK 版本折腾得脑壳疼。后来改成 JDK 11 window64 压缩免安装版也就是 .zip 包从解压到配好环境变量只要几分钟而且换版本、拷贝到别的机器都很自由。今天这篇文章就把这套折腾过很多次的操作流程写透涉及下载渠道、环境变量细节、命令行 still 1.8 的排查思路以及多版本共存的一些实用经验。这篇文章适合两类人看一类是刚入门 Java需要在本机配置第一套 JDK 环境的另一类是身边有好几个 JDK 版本在来回切换、经常被环境变量坑到的老开发。放心整个过程不复杂只要跟着一步步来基本不会再出现配了但没生效这种鬼问题。1. 为什么推荐压缩免安装版三个真实场景先回答一个很多人会问的问题官网明明有 exe 安装包一键下一步不香吗为什么要费劲去解压 zip1.1 zip版和exe安装版的本质区别exe 安装版做的事情比较多把 JDK 文件复制到指定目录、写注册表、往C:\Windows\System32塞java.exe/javaw.exe/javaws.exe、注册卸载信息、甚至可能帮你设置JAVA_HOME和PATH。听起来很省事但它同时给你的系统留下了大量看不见的状态一旦你后面想换版本、卸载重装、或者让两个版本共存这些隐藏状态就会出来捣乱。而压缩免安装版本质上就是一堆文件的集合整个 JDK 的全部内容都打包在 zip 里。你把它当作一个普通压缩包解压到某目录然后通过手动配置环境变量让系统知道它的位置。系统里没有任何隐藏的注册信息想换版本就把解压目录删掉干净利落。1.2 压缩版在三个场景下的明显优势第一个场景是多版本共存。开发老项目要用 JDK 8新项目要用 JDK 11偶尔又要试试 JDK 17。zip 版直接解压三个目录切换时改一下环境变量就行而 exe 版装三个版本在系统里光注册表那堆项就够你喝一壶。第二个场景是快速迁移环境。比如你换了一台新电脑或者要帮同事搭一套一模一样的开发环境。zip 版直接拷贝目录过去配置好环境变量完成。不需要重新走一遍安装向导更不需要重新下载安装包。第三个场景是CI/CD 和服务器环境。我现在打包、跑自动化测试的机器基本都是 zip 版 JDK因为这些机器不想有太多安装痕迹出了问题也能快速回滚到之前的 JDK 目录版本。补充一句如果你在 Linux 环境遇到的是 rpm 包或者 yum 安装的场景思路类似但不在本文范围内本篇只说 Windows 64 位平台的 zip 破解方式。2. 下载JDK 11的渠道与文件校验2.1 下载渠道怎么选JDK 11 的下载渠道主要有下面这几个我实际下载对比过直接说结论渠道是否需要登录版本后续更新建议Oracle 官网需要注册登录官方正式版授受许可协议有条件就用这个比较正宗Eclipse AdoptiumTemurin无需登录社区版长期维护推荐下载体验最顺畅国内云厂商/高校镜像一般无需登录同步上游延迟稍大网络条件受限时用得比较多如果你从 Oracle 官网下载在页面里要勾选Accept License Agreement然后选择 Windows x64 的.zip体积版本文件名大致是jdk-11.0.xx_windows-x64_bin.zip。注意别粗心选了.msi那两个是完全不同的东西。阿杜明Adoptium这个渠道在国内访问题速度比较快它的下载链接直接指向 GitHub Release可以选择OpenJDK11U-jdk_x64_windows_hotspot_11.0.xx_x.zip。我个人更推荐 Adoptium因为它的版本更新节奏很稳而且完全开源免费。如果你在的机房或公司网络访问海外资源很慢用清华 TUNA 镜像站或阿里云镜像也可以那边通常有稳定的 JDK 版本归档。2.2 解压后的目录结构变化拿到 zip 包后解压到某个目录我一般放在D:\Java\下解压出来的目录名类似jdk-11.0.21。这个时候你会发现JDK 11 的目录结构和 JDK 8 相比有不小变化bin可执行文件包括java.exe、javac.exe等confJDK 9 以后新增的配置目录java.security、logging.properties都在这里include本地方法开发用的 C 头文件jmodsJMOD 格式的模块文件这个也是 JDK 9 引入模块系统后出现的legal许可证和版权信息lib类库和运行时所需文件有一个明显的差异是JDK 11 解压之后没有 JRE 目录。以前 JDK 8 会自带一个 jre 目录你可以在没有 JDK 的机器上只拷贝 JRE 来跑 Java 程序。JDK 11 之后官方不再提供独立的 JRE 安装包如果你确实需要一个瘦身运行时环境可以基于jlink命令自己裁剪这个过程后续我找时间单独写一篇这里就不展开了。另一个需要留意的点是解压路径不要带中文和空格。虽然大多数情况下带空格也能用但很多脚本Maven 的某些插件、批处理工具在解析路径时会出幺蛾子。我之前见过有人把 JDK 解压到D:\Program Files (x86)\Java\jdk-11结果 IDEA 里反编译插件直接失效改成D:\Java\jdk-11.0.21之后就正常了。解压工具方面Windows 自带资源管理器就能解压 zip但如果你解压的路径层级比较深或者目录名很长建议用 7-Zip、Bandizip 或 NanaZip遇到长路径问题会少一些。3. 环境变量配置JAVA_HOME与PATH的正确写法解压完成之后真正决定命令行能不能找到java的就是环境变量了。很多教程一上来就让你配却不解释为什么这么配导致很多人只会照着敲一出问题就不会排查。3.1 配置的思路设 JAVA_HOME再用它去拼接 Path在 Windows 上正确且通用的做法是配置两个环境变量新建系统变量JAVA_HOME值为 JDK 解压后的完整目录比如D:\Java\jdk-11.0.21在系统变量Path中新增一行%JAVA_HOME%\bin为什么要把JAVA_HOME单独拆出来而不是直接把D:\Java\jdk-11.0.21\bin写进 Path原因主要有两点切换方便以后要换 JDK 版本只需要把JAVA_HOME改成另一个目录Path 里那个%JAVA_HOME%\bin不需要动。第三方工具依赖Maven、Tomcat、Gradle、IDEA 等大量中间件会去读JAVA_HOME这个环境变量来定位 JDK即使你没把bin加进 Path它们也能工作。注意JAVA_HOME的值末尾不要加反斜杠。如果你写成D:\Java\jdk-11.0.21\某些工具拼接路径时会出现双反斜杠或工具解析错误。这个细节常年有人踩。3.2 配系统变量还是用户变量Windows 环境变量分系统变量和用户变量两类。同样是配置JAVA_HOME放哪一层有讲究系统变量对这台机器的所有用户生效修改需要管理员权限。用户变量只对当前用户生效修改不需要管理员权限。我平时的习惯是配在系统变量里这样无论是当前账号还是其他账号登录JDK 都是可用的。如果你只是自己在普通权限下开发配用户变量也不是不行但有些 IDE 和命令行工具在检测 JDK 时只读系统变量偶尔会遇到工具找不到 JDK 的情况所以干脆统一配系统变量最省事。另外注意修改系统变量之后已经打开的 cmd/PowerShell 窗口不会自动刷新必须新开一个终端窗口才能让改动生效。这个坑排在最常见问题前三名。3.3 CLASSPATH 到底要不要配网上很多老教程会告诉你还要配一个CLASSPATH环境变量内容是.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar。这个在 JDK 5、JDK 6 那会儿确实必要因为那时候 JVM 不会自动加载当前目录的类需要手动指定。从 JDK 1.5 开始classpath的默认值就已经包含了当前目录.JDK 9 引入模块系统之后tools.jar也不在原来位置了。所以JDK 11 的压缩版配置完全不需要设置 CLASSPATH。你配了反而可能干扰 IDE 和构建工具让它们以为某些 jar 在固定路径结果找不到。4. 刚配完就翻车命令行还是1.8的完整排查链路配完了环境变量也都填进去了然后在 cmd 里输入java -version结果屏幕上跳出来的还是java version 1.8.0_xx瞬间心态崩了。这个情况可以说是 JDK 11 配置里最经典的问题也是搜索引擎里的高频问题。下面直接带你走一遍排查链路。4.1 第一步定位当前生效的 java.exe 到底来自哪里在命令行里执行where java这个命令会列出所有出现在PATH中的java.exe的位置按照 Path 顺序从上到下排列。Windows 在执行命令时就按照这个顺序找到第一个匹配的 exe 并运行。所以如果你看到输出第一条是C:\Windows\System32\java.exe那就说明你的java -version调用到的根本不是新配置的 JDK 11而是 System32 目录里的这一个跟JAVA_HOME没关系。4.2 第二步确认 Path 的优先级与 System32 的埋伏Windows 里修改环境变量实际上是把系统 Path 和用户 Path 拼接在一起系统变量在上用户变量在下。C:\Windows\System32通常在系统 Path 里而且位置很靠前。问题就在这如果你以前安装过 JDK 的 exe 版安装程序会往C:\Windows\System32里放三个文件——java.exe、javaw.exe、javaws.exe。它们就像三颗钉子一样钉在那里而由于 System32 的优先位置无论你怎么改JAVA_HOME命令行都会先命中它们。遇到这种情况有两条路如果旧版 JDK 是通过 exe 安装的先到控制面板-程序卸载里把旧 JDK 卸载掉通常这种情况下 System32 下的残留也会被清理。如果卸载完了where java还列出 System32 路径手动去C:\Windows\System32下检查并删除java.exe、javaw.exe、javaws.exe这三个文件。删除前建议备份一下毕竟这是系统目录。提示System32 是管理员目录删除操作需要以管理员身份的 cmd 或文件管理器执行。4.3 第三步检查注册表里的版本指向除了文件exe 安装版还会在系统里留下注册表项。打开regedit定位到HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment如果机器上曾经装过 32 位的 JDK还需要检查HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment看CurrentVersion的值指向哪个版本。如果是1.8而你在 System32 下的 java.exe 又不在了的话部分依赖注册表查询的工具比如某些旧版 IDE 和脚本还是会认为系统当前 JDK 是 1.8。处理方法可以把不需要的旧版本注册表项删掉或者把CurrentVersion改成 JDK 11 对应的值。当然如果你就是想让某些工具识别到其他版本保持旧值也不是不行关键是要清楚这一点。4.4 修复后的完整验证流程排查完之后怎么确认这次真的换过来了我最常用的验证命令是这三条echo %JAVA_HOME% java -version javac -version如果输出分别指向你的 JDK 11 解压路径、11.0.xx和javac 11.0.xx一般就稳了。再用where java看一下路径列表第一条应该变成你的%JAVA_HOME%\bin\java.exe。最后务必开一个新的 cmd 窗口再验证因为已经开的终端不会重新加载环境变量。如果你需要在当前窗口立刻生效可以执行set JAVA_HOMED:\Java\jdk-11.0.21 set Path%JAVA_HOME%\bin;%Path%这两条只对当前窗口临时生效适合快速测试关掉窗口就没了。5. 多版本JDK共存的日常使用经验搞定了 JDK 11很多人下一个问题就是我机器上还有 JDK 8真的要全局只留 JDK 11 吗当然不需要。zip 免安装版给了你更灵活的多版本共存方案。5.1 用切换脚本管理多个 JDK我自己在D:\Java目录下放了多个版本的 JDK 目录D:\Java\jdk-8u202 D:\Java\jdk-11.0.21 D:\Java\jdk-17.0.9然后在同一个目录写几个切换脚本比如切换到 JDK 11 的脚本setjdk11.batecho off set JAVA_HOMED:\Java\jdk-11.0.21 set PATH%JAVA_HOME%\bin;%PATH% echo 已切换到 JDK 11 java -version切换到其他版本就是把JAVA_HOME改成对应目录。注意这个脚本改的是当前 cmd 会话的环境变量不会影响系统全局非常适合在同一个终端里快速切换测试。如果你希望永久切换就需要去系统属性里改全局JAVA_HOME。这里有个常见的坑用setx命令在命令行里设置环境变量比如setx Path %Path%;%JAVA_HOME%\bin如果Path里的内容本身很长一般超过 1024 字符setx写入注册表的时候会截断导致部分 Path 配置丢失。所以优先级最高的还是图形界面的环境变量编辑器它没有长度限制或者用setx时只设置一个中间变量再引用。5.2 与 IDEA、Maven 的配合细节IDEA 这个 IDE 有点特殊它启动时会读取系统JAVA_HOME来决定自己的 JVM但每个项目也可以单独指定 Project SDK。这意味着你在 IDEA 里既可以跑 JDK 11 的项目也可以跑 JDK 8 的项目互不干扰。哪怕系统JAVA_HOME指到了 JDK 11某个项目依然可以选择jdk-8u202目录作为 SDK完全不需要改动全局配置。Maven 也有自己的脾气mvn -v会优先读取JAVA_HOME环境变量如果找不到再回去用java命令。如果你在 Maven 里构建 JDK 11 项目时出现奇怪的编译错误可以先用mvn -v看一下当前 Maven 使用的是哪个 JVM 版本很多时候就是因为JAVA_HOME指到了旧版本而 Maven 自己没报错。注意切换 JDK 版本后Maven 的maven-compiler-plugin还受项目pom.xml里的source和target控制。也就是说哪怕你系统JAVA_HOME已经切到 JDK 11如果 pom 里还写着1.8编译结果依然会按 JDK 8 语言级别生成字节码这不冲突但要注意区分。最后再分享一个小技巧如果你经常要在一个 cmd 窗口里反复切换 JDK 版本可以把上面那个切换脚本放到系统 Path 的某个目录里比如D:\Tools\Scripts这样你在任意路径都能直接输入setjdk11或setjdk8来切换省去每次 cd 到D:\Java的步骤实测下来这类小批处理在 Windows 开发机上非常实用。本文还有配套的精品资源点击获取