1. 为什么 JDK 17 值得你专门折腾一次如果你最近在 Windows 上折腾 Java 项目大概率会遇到一个场景拉下来的开源项目pom.xml里写着maven.compiler.source17/maven.compiler.source或者 Spring Boot 3.x 的启动日志直接甩你一句Unsupported class file major version 61。这时候你才意识到手里那个用了好几年的 JDK 8 已经不够用了。JDK 17 是 Oracle 在 2021 年 9 月发布的 LTS长期支持版本和 JDK 8、JDK 11 一样属于会被长期维护的版本。它带来的变化不是花架子sealed class密封类、record记录类型、switch模式匹配预览、text blocks文本块转正、ZGC 从实验走向生产可用、强封装 JDK 内部 API这个坑后面会重点讲。对普通开发者来说最直观的感受是——写实体类不用再手写一堆 getter/setter/equals/hashCode一个record就搞定写多行 SQL 字符串不用再拼 \n文本块直接贴。但问题也恰恰出在这里。JDK 17 的安装本身不复杂真正让人翻车的是环境变量配置和多版本共存。我见过太多人下载完安装包一路 Next结果java -version出来的还是 1.8或者 IDEA 里配了 17 但 Maven 编译报cannot determine path to tools.jar library for 17。这些问题的根子都不在 JDK 本身而在于 Windows 的环境变量机制和 JDK 17 的目录结构变化。这篇内容适合三类人一是第一次在 Windows 上装 JDK 17 的新手二是机器上已经有 JDK 8 想再加一个 17 的老手三是被环境变量折磨过、想彻底搞明白JAVA_HOME和Path到底怎么配合的人。我会把下载、安装、环境变量、验证、多版本切换、常见报错排查这一整条链路讲透每一步都告诉你为什么这么做而不是让你照着截图点下一步。2. 下载环节选对包比装得快更重要2.1 Oracle JDK 还是 OpenJDK 发行版很多人一上来就搜JDK17 下载第一个结果往往是 Oracle 官网。但这里有个现实问题Oracle JDK 从 JDK 17 开始采用了 NFTC 许可个人开发和测试免费但商业生产环境使用需要付费订阅。如果你只是本地学习、跑跑开源项目用 Oracle JDK 没问题但如果你在公司项目里用法务那边可能会有意见。所以更稳妥的选择是 OpenJDK 的各种发行版。目前主流的有几个发行版维护方特点适合场景Oracle JDKOracle官方原版含少量商业特性个人学习、测试Eclipse TemurinEclipse 基金会社区驱动免费无许可顾虑企业生产、个人均可Amazon CorrettoAmazonAWS 生态优化长期免费云上部署、企业Microsoft Build of OpenJDK微软Windows 集成好含 MSI 安装包Windows 开发者Azul ZuluAzul提供多种打包格式跨平台、嵌入式我个人的习惯是Windows 本地开发用 Eclipse Temurin 或者 Microsoft Build前者社区活跃、更新及时后者对 Windows 的 MSI 安装支持最顺滑。下面以 Eclipse Temurin 为例走一遍流程其他发行版的操作逻辑完全一致。2.2 下载时的版本号和架构选择打开 Adoptium 官网Eclipse Temurin 的发布站点你会看到版本选择器。这里有几个关键点Version选 17 - LTS不要选 17.0.x 的具体小版本除非你有明确的补丁需求。LTS 会持续收到安全更新。Operating System选 Windows。Architecture选 x64除非你的机器是 ARM 架构比如 Surface Pro X 这类那要选 aarch64。Package Type有两个选项JDK 和 JRE。一定要选 JDKJRE 只是运行环境没有编译器和开发工具你后面用不了javac。Installer格式选.msi这是 Windows 的原生安装包会自动处理一些注册表和目录问题比.zip省心。提示如果你下载的是.zip免安装版解压后需要手动配置环境变量而且不会自动注册到系统。新手建议直接用.msi。下载下来的文件名大概长这样OpenJDK17U-jdk_x64_windows_hotspot_17.0.9_9.msi。文件大小在 150MB 左右如果只有几十 MB那大概率是 JRE 或者下载不完整。2.3 校验安装包完整性这一步很多人会跳过但我建议你养成习惯。下载完成后在文件所在目录打开 PowerShell执行Get-FileHash .\OpenJDK17U-jdk_x64_windows_hotspot_17.0.9_9.msi -Algorithm SHA256然后把输出的哈希值和官网提供的 SHA256 值对比。如果一致说明文件没被篡改或损坏如果不一致重新下载。这个习惯在下载任何开发工具时都值得保留尤其是从非官方镜像站下载的时候。3. 安装过程路径选择里藏着后面所有的坑3.1 安装向导里的两个关键决策双击.msi文件后向导会问你几个问题。第一个是安装类型选Typical就行它会安装完整的 JDK 组件。第二个是安装路径默认是C:\Program Files\Eclipse Adoptium\jdk-17.0.9.9-hotspot\。这里我要重点说路径问题。默认路径有两个坑点第一Program Files中间有个空格。绝大多数场景下没问题但某些老旧的构建脚本、批处理文件对空格路径处理不好会莫名其妙报错。我遇到过用 Ant 构建的老项目因为路径空格导致JAVA_HOME解析失败。第二路径太长。C:\Program Files\Eclipse Adoptium\jdk-17.0.9.9-hotspot\这一串在命令行里敲起来费劲而且某些工具对路径长度有限制。所以我建议改成短路径比如D:\dev\jdk17或者C:\Java\jdk17。注意两点路径里不要有中文不要有空格。中文路径在某些编码场景下会导致javac读取源文件失败这个坑很隐蔽排查起来很痛苦。3.2 安装完成后先别急着配环境变量安装完成后先别急着去配环境变量。打开文件资源管理器进到你的安装目录确认目录结构是这样的D:\dev\jdk17\ ├── bin\ │ ├── java.exe │ ├── javac.exe │ ├── jar.exe │ └── ... ├── conf\ ├── include\ ├── jmods\ ├── legal\ ├── lib\ └── release重点确认bin目录下有java.exe和javac.exe。如果只有java.exe没有javac.exe那你装的是 JRE 不是 JDK需要重新下载。另外注意JDK 17 的目录里没有jre子目录了。JDK 8 时代JDK 目录下会有一个独立的jre文件夹JDK 9 之后这个结构被取消了运行时环境被模块化整合进了lib目录。这个变化导致一些老教程里的配置方法失效后面讲环境变量时会再提到。3.3 为什么安装程序没有自动配好环境变量很多人会问为什么我装了 JDK命令行里敲java还是提示不是内部或外部命令因为.msi安装程序默认只把java.exe的路径加到了系统Path里有些版本连这个都不做但不会设置JAVA_HOME。JAVA_HOME是很多工具用来定位 JDK 安装目录的约定变量。Maven、Gradle、Tomcat、IDEA 的某些配置项都会去读这个变量。没有它这些工具要么找不到 JDK要么用错版本。所以环境变量必须手动配而且JAVA_HOME和Path要配合着配。4. 环境变量配置JAVA_HOME 和 Path 的分工逻辑4.1 先理解 Windows 环境变量的查找机制在动手之前花两分钟搞明白 Windows 是怎么找java命令的后面所有问题你都能自己推理出来。当你在命令行敲java时系统会做这几件事先看当前目录下有没有java.exe。如果没有按Path变量里列出的目录顺序逐个去找java.exe。找到第一个就执行后面的不再看。所以Path决定了系统能找到哪些命令而顺序决定了同名命令用哪个版本。这就是多版本共存的核心机制。那JAVA_HOME是干嘛的它本身不参与命令查找它是给其他程序读的。比如 Maven 启动脚本里会写%JAVA_HOME%\bin\java它不依赖Path而是直接通过JAVA_HOME拼出完整路径。这样做的好处是即使Path里配的是 JDK 8只要JAVA_HOME指向 JDK 17Maven 就会用 17 来跑。理解了这个分工你就明白为什么两个都要配而且为什么有时候配了Path还是不行——因为某个工具读的是JAVA_HOME而你只配了Path。4.2 配置 JAVA_HOME 的完整步骤按下Win R输入sysdm.cpl回车打开系统属性。点高级选项卡再点环境变量按钮。你会看到上下两个区域上面是用户变量下面是系统变量。这里有个选择配在用户变量还是系统变量用户变量只对当前登录用户生效不需要管理员权限切换用户后不共享。系统变量对所有用户生效需要管理员权限。如果你是自己电脑自己用配在用户变量里就够了而且更安全。如果是公司电脑多人共用或者你想一劳永逸配在系统变量里。我下面以系统变量为例用户变量操作完全一样。在系统变量区域点新建填写变量名JAVA_HOME变量值D:\dev\jdk17换成你自己的实际路径不要带\bin注意JAVA_HOME的值是 JDK 的根目录不是bin目录。这是新手最容易犯的错。如果你写成D:\dev\jdk17\bin那么 Maven 拼出来的路径会变成D:\dev\jdk17\bin\bin\java直接报错。点确定保存。4.3 配置 Path 变量的正确姿势在系统变量区域找到Path选中后点编辑。你会看到一个列表每一行是一个目录。点新建添加一行%JAVA_HOME%\bin这里用%JAVA_HOME%而不是写死路径好处是以后换 JDK 版本只需要改JAVA_HOME一个地方Path不用动。这是配置环境变量的最佳实践。然后把这一行移到最上面。为什么因为如果你的系统里之前装过 JDK 8Path里可能已经有C:\Program Files\Java\jdk1.8.0_xxx\bin或者C:\ProgramData\Oracle\Java\javapath这样的条目。系统按顺序查找如果旧的排在前面你敲java出来的还是 1.8。提示C:\ProgramData\Oracle\Java\javapath这个目录是 Oracle 安装器自动加的里面是java.exe的快捷方式。很多人配了JAVA_HOME却发现java -version还是旧版本罪魁祸首就是它。要么把它删掉要么把%JAVA_HOME%\bin移到它前面。配置完成后一路点确定关闭所有窗口。4.4 验证配置是否生效关键一步关闭所有已经打开的命令行窗口。环境变量的修改不会自动同步到已打开的终端必须重新开一个。按Win R输入cmd回车。依次执行echo %JAVA_HOME%应该输出D:\dev\jdk17你的实际路径。java -version应该输出类似openjdk version 17.0.9 2023-10-17 OpenJDK Runtime Environment Temurin-17.0.99 (build 17.0.99) OpenJDK 64-Bit Server VM Temurin-17.0.99 (build 17.0.99, mixed mode, sharing)javac -version应该输出javac 17.0.9。如果java -version出来的还是 1.8回到 4.3 检查Path顺序。如果提示不是内部或外部命令检查%JAVA_HOME%\bin是否拼写正确以及JAVA_HOME是否真的指向了存在的目录。5. 多版本共存让 JDK 8 和 JDK 17 和平相处5.1 为什么不能简单地把旧版本删掉很多教程会告诉你卸载旧版本再装新版本但现实中这往往行不通。你手上可能有老项目还在用 JDK 8 编译有些依赖库在 JDK 17 下会报模块访问错误。比如用了sun.misc.Unsafe的库在 JDK 17 的强封装下会直接抛InaccessibleObjectException。这时候你需要的是两个版本共存按项目切换。5.2 用 JAVA_HOME 做版本切换开关最干净的方案是Path里只保留%JAVA_HOME%\bin这一条 Java 相关路径然后通过改JAVA_HOME的值来切换版本。假设你有两个 JDKJDK 8D:\dev\jdk8JDK 17D:\dev\jdk17想用 17 时把JAVA_HOME设为D:\dev\jdk17想用 8 时改成D:\dev\jdk8。改完重开命令行java -version就跟着变了。这个方案的好处是只有一个切换点不会出现Path里多个 Java 路径打架的情况。缺点是每次切换要手动改环境变量稍微麻烦。5.3 用批处理脚本一键切换如果你切换频繁可以写两个.bat文件放在桌面右键以管理员身份运行即可切换。switch-to-jdk17.batecho off setx JAVA_HOME D:\dev\jdk17 /M echo JDK 17 activated. Please reopen your terminal. pauseswitch-to-jdk8.batecho off setx JAVA_HOME D:\dev\jdk8 /M echo JDK 8 activated. Please reopen your terminal. pausesetx是永久设置环境变量的命令/M表示系统级需要管理员权限。注意setx设置的值不会在当前命令行立即生效必须新开窗口。注意setx有一个坑如果变量值超过 1024 字符会被截断。JAVA_HOME一般不会超但如果你用它设置Path就要小心了Path很容易超长。所以切换脚本只改JAVA_HOME不动Path。5.4 IDEA 里的版本配置是独立的需要特别说明IntelliJ IDEA 有自己的 JDK 配置不完全依赖系统环境变量。在 IDEA 里你可以在File - Project Structure - Project里设置 Project SDK 和 Language Level在Settings - Build, Execution, Deployment - Build Tools - Maven - Runner里设置 Maven 用的 JRE。这意味着即使系统JAVA_HOME指向 JDK 8你完全可以让 IDEA 里的某个项目用 JDK 17 编译。IDEA 会直接调用你指定的 JDK 路径不走Path查找。所以做 Java 开发时系统环境变量主要影响的是命令行工具Maven、Gradle 命令行版IDEA 内部是另一套逻辑。6. 那些年我们踩过的报错和排查思路6.1 could not find java executable in JAVA_HOME or PATH这个报错通常出现在你运行某个依赖 Java 的工具时比如 Elasticsearch、Logstash、某些 Maven 插件。它的意思是工具去找JAVA_HOME指向的目录下的bin\java.exe没找到退而求其次去Path里找也没找到。排查顺序echo %JAVA_HOME%看变量是否存在值是否正确。进到%JAVA_HOME%\bin目录确认java.exe真的在那里。如果JAVA_HOME末尾不小心带了分号或者空格也会导致拼接出的路径无效。用echo [%JAVA_HOME%]把变量值用方括号包起来能看出有没有多余空格。检查Path里是否有%JAVA_HOME%\bin以及顺序是否被其他 Java 路径抢先。6.2 cannot determine path to tools.jar library for 17这个报错我在热词里看到有人遇到路径是d:\soft\jdk17。它的根源是某些老版本的 Maven 插件或者构建工具会去JAVA_HOME\lib目录下找tools.jar。但 JDK 9 之后tools.jar被移除了相关功能被模块化到jdk.compiler等模块里。遇到这个报错说明你用的某个工具版本太老还在用 JDK 8 时代的逻辑找tools.jar。解决方案有三个方向升级那个工具到支持 JDK 17 的版本。比如老版本的maven-compiler-plugin换成 3.11.0 以上。如果升级不了在工具配置里显式指定fork为true让它用外部javac而不是内置编译器。实在不行这个项目就用 JDK 8 编译别硬上 17。6.3 环境变量配了但 IDEA 终端里不生效IDEA 内置的 Terminal 有时候不会继承最新的系统环境变量尤其是你刚改完环境变量没重启 IDEA 的时候。解决办法很简单完全关闭 IDEA不是最小化是退出进程重新打开。如果还不行在 IDEA 的Settings - Tools - Terminal里检查Environment variables配置看有没有覆盖系统变量。6.4 Path 变量被改坏了怎么办这是最吓人的情况编辑Path时不小心删了系统自带的条目导致一堆命令用不了。预防措施是编辑前先点编辑文本按钮把整个Path的值复制到记事本备份一份。如果不幸改坏了Windows 有一个默认的Path值可以参考%SystemRoot%\system32 %SystemRoot% %SystemRoot%\System32\Wbem %SystemRoot%\System32\WindowsPowerShell\v1.0\ %SystemRoot%\System32\OpenSSH\把这些加回去再加上你自己的开发工具路径。实在记不清可以找一台同版本 Windows 的机器对照。6.5 命令行里 java 和 javac 版本不一致有时候java -version显示 17但javac -version显示 1.8。这说明Path里java.exe和javac.exe来自不同目录。可能的原因是C:\Windows\System32下有一个java.exe某些软件安装时塞进去的而javac.exe只在你配的 JDK 目录里。排查方法where java where javacwhere命令会列出所有匹配的可执行文件路径按Path顺序排列。看第一个java和第一个javac是否在同一个bin目录下。如果不是把干扰项从Path里移除或者调整顺序。7. 装完之后几个让开发更顺手的收尾动作7.1 配置 Maven 使用 JDK 17如果你用 Maven装完 JDK 17 后建议在settings.xml或者项目pom.xml里明确指定编译版本。最稳妥的方式是在pom.xml的properties里写properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target maven.compiler.release17/maven.compiler.release /propertiesrelease参数比source/target更严格它会确保编译时使用的 API 也限制在 JDK 17 范围内避免你在 JDK 17 上编译出依赖更高版本 API 的字节码。7.2 检查 IDE 的编码设置JDK 17 默认的字符编码在 Windows 上仍然是跟随系统区域设置中文 Windows 下是 GBK。但现代项目基本都用 UTF-8。建议在 IDEA 里把File Encodings全部设为 UTF-8并且在编译参数里加上-encoding UTF-8。否则你可能会遇到编码 GBK 的不可映射字符这种经典报错。7.3 关于 JAVA_HOME 的一个常见误解最后澄清一个很多人搞混的点JAVA_HOME不是 Java 官方规定的标准变量它是社区约定俗成的。不同工具对它的依赖程度不一样。Maven、Gradle、Tomcat 认它但有些工具只认Path。所以最保险的做法是JAVA_HOME和Path都配好两者指向同一个 JDK。这样无论工具读哪个结果都一致。我在实际配置中还有一个习惯在JAVA_HOME配好之后顺手在命令行里跑一个java -XshowSettings:properties -version 21 | findstr java.home它会打印出 JVM 实际使用的java.home路径。这个路径应该和你配的JAVA_HOME一致注意 JVM 的java.home可能指向 JDK 根目录或jre子目录JDK 17 下就是根目录。如果不一致说明有别的配置在干扰顺着这条线索查下去基本都能定位到问题。 
长河君 · 2026/9/20 14:21:57 · 阅读 1.2k Windows 上 JDK 17 安装与环境变量配置全指南：多版本共存与常见报错排查
1. 为什么 JDK 17 值得你专门折腾一次如果你最近在 Windows 上折腾 Java 项目大概率会遇到一个场景拉下来的开源项目pom.xml里写着maven.compiler.source17/maven.compiler.source或者 Spring Boot 3.x 的启动日志直接甩你一句Unsupported class file major version 61。这时候你才意识到手里那个用了好几年的 JDK 8 已经不够用了。JDK 17 是 Oracle 在 2021 年 9 月发布的 LTS长期支持版本和 JDK 8、JDK 11 一样属于会被长期维护的版本。它带来的变化不是花架子sealed class密封类、record记录类型、switch模式匹配预览、text blocks文本块转正、ZGC 从实验走向生产可用、强封装 JDK 内部 API这个坑后面会重点讲。对普通开发者来说最直观的感受是——写实体类不用再手写一堆 getter/setter/equals/hashCode一个record就搞定写多行 SQL 字符串不用再拼 \n文本块直接贴。但问题也恰恰出在这里。JDK 17 的安装本身不复杂真正让人翻车的是环境变量配置和多版本共存。我见过太多人下载完安装包一路 Next结果java -version出来的还是 1.8或者 IDEA 里配了 17 但 Maven 编译报cannot determine path to tools.jar library for 17。这些问题的根子都不在 JDK 本身而在于 Windows 的环境变量机制和 JDK 17 的目录结构变化。这篇内容适合三类人一是第一次在 Windows 上装 JDK 17 的新手二是机器上已经有 JDK 8 想再加一个 17 的老手三是被环境变量折磨过、想彻底搞明白JAVA_HOME和Path到底怎么配合的人。我会把下载、安装、环境变量、验证、多版本切换、常见报错排查这一整条链路讲透每一步都告诉你为什么这么做而不是让你照着截图点下一步。2. 下载环节选对包比装得快更重要2.1 Oracle JDK 还是 OpenJDK 发行版很多人一上来就搜JDK17 下载第一个结果往往是 Oracle 官网。但这里有个现实问题Oracle JDK 从 JDK 17 开始采用了 NFTC 许可个人开发和测试免费但商业生产环境使用需要付费订阅。如果你只是本地学习、跑跑开源项目用 Oracle JDK 没问题但如果你在公司项目里用法务那边可能会有意见。所以更稳妥的选择是 OpenJDK 的各种发行版。目前主流的有几个发行版维护方特点适合场景Oracle JDKOracle官方原版含少量商业特性个人学习、测试Eclipse TemurinEclipse 基金会社区驱动免费无许可顾虑企业生产、个人均可Amazon CorrettoAmazonAWS 生态优化长期免费云上部署、企业Microsoft Build of OpenJDK微软Windows 集成好含 MSI 安装包Windows 开发者Azul ZuluAzul提供多种打包格式跨平台、嵌入式我个人的习惯是Windows 本地开发用 Eclipse Temurin 或者 Microsoft Build前者社区活跃、更新及时后者对 Windows 的 MSI 安装支持最顺滑。下面以 Eclipse Temurin 为例走一遍流程其他发行版的操作逻辑完全一致。2.2 下载时的版本号和架构选择打开 Adoptium 官网Eclipse Temurin 的发布站点你会看到版本选择器。这里有几个关键点Version选 17 - LTS不要选 17.0.x 的具体小版本除非你有明确的补丁需求。LTS 会持续收到安全更新。Operating System选 Windows。Architecture选 x64除非你的机器是 ARM 架构比如 Surface Pro X 这类那要选 aarch64。Package Type有两个选项JDK 和 JRE。一定要选 JDKJRE 只是运行环境没有编译器和开发工具你后面用不了javac。Installer格式选.msi这是 Windows 的原生安装包会自动处理一些注册表和目录问题比.zip省心。提示如果你下载的是.zip免安装版解压后需要手动配置环境变量而且不会自动注册到系统。新手建议直接用.msi。下载下来的文件名大概长这样OpenJDK17U-jdk_x64_windows_hotspot_17.0.9_9.msi。文件大小在 150MB 左右如果只有几十 MB那大概率是 JRE 或者下载不完整。2.3 校验安装包完整性这一步很多人会跳过但我建议你养成习惯。下载完成后在文件所在目录打开 PowerShell执行Get-FileHash .\OpenJDK17U-jdk_x64_windows_hotspot_17.0.9_9.msi -Algorithm SHA256然后把输出的哈希值和官网提供的 SHA256 值对比。如果一致说明文件没被篡改或损坏如果不一致重新下载。这个习惯在下载任何开发工具时都值得保留尤其是从非官方镜像站下载的时候。3. 安装过程路径选择里藏着后面所有的坑3.1 安装向导里的两个关键决策双击.msi文件后向导会问你几个问题。第一个是安装类型选Typical就行它会安装完整的 JDK 组件。第二个是安装路径默认是C:\Program Files\Eclipse Adoptium\jdk-17.0.9.9-hotspot\。这里我要重点说路径问题。默认路径有两个坑点第一Program Files中间有个空格。绝大多数场景下没问题但某些老旧的构建脚本、批处理文件对空格路径处理不好会莫名其妙报错。我遇到过用 Ant 构建的老项目因为路径空格导致JAVA_HOME解析失败。第二路径太长。C:\Program Files\Eclipse Adoptium\jdk-17.0.9.9-hotspot\这一串在命令行里敲起来费劲而且某些工具对路径长度有限制。所以我建议改成短路径比如D:\dev\jdk17或者C:\Java\jdk17。注意两点路径里不要有中文不要有空格。中文路径在某些编码场景下会导致javac读取源文件失败这个坑很隐蔽排查起来很痛苦。3.2 安装完成后先别急着配环境变量安装完成后先别急着去配环境变量。打开文件资源管理器进到你的安装目录确认目录结构是这样的D:\dev\jdk17\ ├── bin\ │ ├── java.exe │ ├── javac.exe │ ├── jar.exe │ └── ... ├── conf\ ├── include\ ├── jmods\ ├── legal\ ├── lib\ └── release重点确认bin目录下有java.exe和javac.exe。如果只有java.exe没有javac.exe那你装的是 JRE 不是 JDK需要重新下载。另外注意JDK 17 的目录里没有jre子目录了。JDK 8 时代JDK 目录下会有一个独立的jre文件夹JDK 9 之后这个结构被取消了运行时环境被模块化整合进了lib目录。这个变化导致一些老教程里的配置方法失效后面讲环境变量时会再提到。3.3 为什么安装程序没有自动配好环境变量很多人会问为什么我装了 JDK命令行里敲java还是提示不是内部或外部命令因为.msi安装程序默认只把java.exe的路径加到了系统Path里有些版本连这个都不做但不会设置JAVA_HOME。JAVA_HOME是很多工具用来定位 JDK 安装目录的约定变量。Maven、Gradle、Tomcat、IDEA 的某些配置项都会去读这个变量。没有它这些工具要么找不到 JDK要么用错版本。所以环境变量必须手动配而且JAVA_HOME和Path要配合着配。4. 环境变量配置JAVA_HOME 和 Path 的分工逻辑4.1 先理解 Windows 环境变量的查找机制在动手之前花两分钟搞明白 Windows 是怎么找java命令的后面所有问题你都能自己推理出来。当你在命令行敲java时系统会做这几件事先看当前目录下有没有java.exe。如果没有按Path变量里列出的目录顺序逐个去找java.exe。找到第一个就执行后面的不再看。所以Path决定了系统能找到哪些命令而顺序决定了同名命令用哪个版本。这就是多版本共存的核心机制。那JAVA_HOME是干嘛的它本身不参与命令查找它是给其他程序读的。比如 Maven 启动脚本里会写%JAVA_HOME%\bin\java它不依赖Path而是直接通过JAVA_HOME拼出完整路径。这样做的好处是即使Path里配的是 JDK 8只要JAVA_HOME指向 JDK 17Maven 就会用 17 来跑。理解了这个分工你就明白为什么两个都要配而且为什么有时候配了Path还是不行——因为某个工具读的是JAVA_HOME而你只配了Path。4.2 配置 JAVA_HOME 的完整步骤按下Win R输入sysdm.cpl回车打开系统属性。点高级选项卡再点环境变量按钮。你会看到上下两个区域上面是用户变量下面是系统变量。这里有个选择配在用户变量还是系统变量用户变量只对当前登录用户生效不需要管理员权限切换用户后不共享。系统变量对所有用户生效需要管理员权限。如果你是自己电脑自己用配在用户变量里就够了而且更安全。如果是公司电脑多人共用或者你想一劳永逸配在系统变量里。我下面以系统变量为例用户变量操作完全一样。在系统变量区域点新建填写变量名JAVA_HOME变量值D:\dev\jdk17换成你自己的实际路径不要带\bin注意JAVA_HOME的值是 JDK 的根目录不是bin目录。这是新手最容易犯的错。如果你写成D:\dev\jdk17\bin那么 Maven 拼出来的路径会变成D:\dev\jdk17\bin\bin\java直接报错。点确定保存。4.3 配置 Path 变量的正确姿势在系统变量区域找到Path选中后点编辑。你会看到一个列表每一行是一个目录。点新建添加一行%JAVA_HOME%\bin这里用%JAVA_HOME%而不是写死路径好处是以后换 JDK 版本只需要改JAVA_HOME一个地方Path不用动。这是配置环境变量的最佳实践。然后把这一行移到最上面。为什么因为如果你的系统里之前装过 JDK 8Path里可能已经有C:\Program Files\Java\jdk1.8.0_xxx\bin或者C:\ProgramData\Oracle\Java\javapath这样的条目。系统按顺序查找如果旧的排在前面你敲java出来的还是 1.8。提示C:\ProgramData\Oracle\Java\javapath这个目录是 Oracle 安装器自动加的里面是java.exe的快捷方式。很多人配了JAVA_HOME却发现java -version还是旧版本罪魁祸首就是它。要么把它删掉要么把%JAVA_HOME%\bin移到它前面。配置完成后一路点确定关闭所有窗口。4.4 验证配置是否生效关键一步关闭所有已经打开的命令行窗口。环境变量的修改不会自动同步到已打开的终端必须重新开一个。按Win R输入cmd回车。依次执行echo %JAVA_HOME%应该输出D:\dev\jdk17你的实际路径。java -version应该输出类似openjdk version 17.0.9 2023-10-17 OpenJDK Runtime Environment Temurin-17.0.99 (build 17.0.99) OpenJDK 64-Bit Server VM Temurin-17.0.99 (build 17.0.99, mixed mode, sharing)javac -version应该输出javac 17.0.9。如果java -version出来的还是 1.8回到 4.3 检查Path顺序。如果提示不是内部或外部命令检查%JAVA_HOME%\bin是否拼写正确以及JAVA_HOME是否真的指向了存在的目录。5. 多版本共存让 JDK 8 和 JDK 17 和平相处5.1 为什么不能简单地把旧版本删掉很多教程会告诉你卸载旧版本再装新版本但现实中这往往行不通。你手上可能有老项目还在用 JDK 8 编译有些依赖库在 JDK 17 下会报模块访问错误。比如用了sun.misc.Unsafe的库在 JDK 17 的强封装下会直接抛InaccessibleObjectException。这时候你需要的是两个版本共存按项目切换。5.2 用 JAVA_HOME 做版本切换开关最干净的方案是Path里只保留%JAVA_HOME%\bin这一条 Java 相关路径然后通过改JAVA_HOME的值来切换版本。假设你有两个 JDKJDK 8D:\dev\jdk8JDK 17D:\dev\jdk17想用 17 时把JAVA_HOME设为D:\dev\jdk17想用 8 时改成D:\dev\jdk8。改完重开命令行java -version就跟着变了。这个方案的好处是只有一个切换点不会出现Path里多个 Java 路径打架的情况。缺点是每次切换要手动改环境变量稍微麻烦。5.3 用批处理脚本一键切换如果你切换频繁可以写两个.bat文件放在桌面右键以管理员身份运行即可切换。switch-to-jdk17.batecho off setx JAVA_HOME D:\dev\jdk17 /M echo JDK 17 activated. Please reopen your terminal. pauseswitch-to-jdk8.batecho off setx JAVA_HOME D:\dev\jdk8 /M echo JDK 8 activated. Please reopen your terminal. pausesetx是永久设置环境变量的命令/M表示系统级需要管理员权限。注意setx设置的值不会在当前命令行立即生效必须新开窗口。注意setx有一个坑如果变量值超过 1024 字符会被截断。JAVA_HOME一般不会超但如果你用它设置Path就要小心了Path很容易超长。所以切换脚本只改JAVA_HOME不动Path。5.4 IDEA 里的版本配置是独立的需要特别说明IntelliJ IDEA 有自己的 JDK 配置不完全依赖系统环境变量。在 IDEA 里你可以在File - Project Structure - Project里设置 Project SDK 和 Language Level在Settings - Build, Execution, Deployment - Build Tools - Maven - Runner里设置 Maven 用的 JRE。这意味着即使系统JAVA_HOME指向 JDK 8你完全可以让 IDEA 里的某个项目用 JDK 17 编译。IDEA 会直接调用你指定的 JDK 路径不走Path查找。所以做 Java 开发时系统环境变量主要影响的是命令行工具Maven、Gradle 命令行版IDEA 内部是另一套逻辑。6. 那些年我们踩过的报错和排查思路6.1 could not find java executable in JAVA_HOME or PATH这个报错通常出现在你运行某个依赖 Java 的工具时比如 Elasticsearch、Logstash、某些 Maven 插件。它的意思是工具去找JAVA_HOME指向的目录下的bin\java.exe没找到退而求其次去Path里找也没找到。排查顺序echo %JAVA_HOME%看变量是否存在值是否正确。进到%JAVA_HOME%\bin目录确认java.exe真的在那里。如果JAVA_HOME末尾不小心带了分号或者空格也会导致拼接出的路径无效。用echo [%JAVA_HOME%]把变量值用方括号包起来能看出有没有多余空格。检查Path里是否有%JAVA_HOME%\bin以及顺序是否被其他 Java 路径抢先。6.2 cannot determine path to tools.jar library for 17这个报错我在热词里看到有人遇到路径是d:\soft\jdk17。它的根源是某些老版本的 Maven 插件或者构建工具会去JAVA_HOME\lib目录下找tools.jar。但 JDK 9 之后tools.jar被移除了相关功能被模块化到jdk.compiler等模块里。遇到这个报错说明你用的某个工具版本太老还在用 JDK 8 时代的逻辑找tools.jar。解决方案有三个方向升级那个工具到支持 JDK 17 的版本。比如老版本的maven-compiler-plugin换成 3.11.0 以上。如果升级不了在工具配置里显式指定fork为true让它用外部javac而不是内置编译器。实在不行这个项目就用 JDK 8 编译别硬上 17。6.3 环境变量配了但 IDEA 终端里不生效IDEA 内置的 Terminal 有时候不会继承最新的系统环境变量尤其是你刚改完环境变量没重启 IDEA 的时候。解决办法很简单完全关闭 IDEA不是最小化是退出进程重新打开。如果还不行在 IDEA 的Settings - Tools - Terminal里检查Environment variables配置看有没有覆盖系统变量。6.4 Path 变量被改坏了怎么办这是最吓人的情况编辑Path时不小心删了系统自带的条目导致一堆命令用不了。预防措施是编辑前先点编辑文本按钮把整个Path的值复制到记事本备份一份。如果不幸改坏了Windows 有一个默认的Path值可以参考%SystemRoot%\system32 %SystemRoot% %SystemRoot%\System32\Wbem %SystemRoot%\System32\WindowsPowerShell\v1.0\ %SystemRoot%\System32\OpenSSH\把这些加回去再加上你自己的开发工具路径。实在记不清可以找一台同版本 Windows 的机器对照。6.5 命令行里 java 和 javac 版本不一致有时候java -version显示 17但javac -version显示 1.8。这说明Path里java.exe和javac.exe来自不同目录。可能的原因是C:\Windows\System32下有一个java.exe某些软件安装时塞进去的而javac.exe只在你配的 JDK 目录里。排查方法where java where javacwhere命令会列出所有匹配的可执行文件路径按Path顺序排列。看第一个java和第一个javac是否在同一个bin目录下。如果不是把干扰项从Path里移除或者调整顺序。7. 装完之后几个让开发更顺手的收尾动作7.1 配置 Maven 使用 JDK 17如果你用 Maven装完 JDK 17 后建议在settings.xml或者项目pom.xml里明确指定编译版本。最稳妥的方式是在pom.xml的properties里写properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target maven.compiler.release17/maven.compiler.release /propertiesrelease参数比source/target更严格它会确保编译时使用的 API 也限制在 JDK 17 范围内避免你在 JDK 17 上编译出依赖更高版本 API 的字节码。7.2 检查 IDE 的编码设置JDK 17 默认的字符编码在 Windows 上仍然是跟随系统区域设置中文 Windows 下是 GBK。但现代项目基本都用 UTF-8。建议在 IDEA 里把File Encodings全部设为 UTF-8并且在编译参数里加上-encoding UTF-8。否则你可能会遇到编码 GBK 的不可映射字符这种经典报错。7.3 关于 JAVA_HOME 的一个常见误解最后澄清一个很多人搞混的点JAVA_HOME不是 Java 官方规定的标准变量它是社区约定俗成的。不同工具对它的依赖程度不一样。Maven、Gradle、Tomcat 认它但有些工具只认Path。所以最保险的做法是JAVA_HOME和Path都配好两者指向同一个 JDK。这样无论工具读哪个结果都一致。我在实际配置中还有一个习惯在JAVA_HOME配好之后顺手在命令行里跑一个java -XshowSettings:properties -version 21 | findstr java.home它会打印出 JVM 实际使用的java.home路径。这个路径应该和你配的JAVA_HOME一致注意 JVM 的java.home可能指向 JDK 根目录或jre子目录JDK 17 下就是根目录。如果不一致说明有别的配置在干扰顺着这条线索查下去基本都能定位到问题。