★ FEATURED ARTICLE 各位做 Java 开发的朋友或者正在自学 Java 的路上被环境折腾得死去活来的同学你们有没有遇到过这种诡异情况java -version显示的是 JDK 17javac -version却告诉你这是 1.8或者装新版本的时候系统死活提示找不到 JDK又或者卸载旧版本之后java命令居然还能用但就是不知道它从哪里冒出来的这些问题的根源几乎都指向同一个操作JDK 的卸载与安装没有做干净、没有做对。说实话JDK 的安装本身不难难的是理解它背后的运行机制以及在不同操作系统下正确处理环境变量和残留文件。这篇文章我就以实操经验为主线把 JDK 从卸载到安装的完整链路、容易踩的坑、以及多版本并存的正确姿势一次讲清楚。1. 为什么卸载 JDK 比安装还容易翻车先说一个反直觉的结论在 JDK 这件事上卸载比安装更容易把系统搞坏。因为安装是一个从无到有的过程而卸载面对的是一个已经被各种环境变量、注册表项Windows、软链接Linux/macOS绑定在一起的复杂状态。1.1 装完找不到 JDK到底是谁的锅很多人遇到找不到 jdk的第一反应是重新下载安装包点开安装向导走一遍结果发现还是找不到。实际上99% 的情况不是 JDK 没装上而是环境变量没生效或者配置被其他位置的 JDK 抢先了。我举个真实例子。我之前帮一个朋友排查问题他电脑装了 JDK 8 和 JDK 17想把 17 设为默认。他在系统属性-环境变量里把 JAVA_HOME 改成了 JDK 17 的目录保存、关窗口打开新 cmd 窗口执行java -version结果还是 1.8。我当时第一反应就是让他执行where java结果输出三条路径C:\Program Files\Common Files\Oracle\Java\javapath\java.exe C:\Program Files\Java\jdk-17\bin\java.exe C:\Program Files\Java\jdk1.8.0_202\bin\java.exe问题出在哪C:\Program Files\Common Files\Oracle\Java\javapath这个目录是 Oracle 的公共 Java 路径它在 PATH 环境变量里的优先级高于用户自定义的 JAVA_HOME。当年他装 JDK 8 的时候Oracle 安装器自动把这个路径写进了系统 PATH排在最前面。所以不管 JAVA_HOME 怎么改cmd 找到的永远是公共路径里那个 java.exe。教训排查找不到 JDK或版本不对问题时第一步不是重新安装而是用where javaWindows或which -a javaLinux/macOS看系统到底找到了哪几个 java顺序是什么。1.2 卸载不干净的三个重灾区根据我对大量环境故障案例的观察卸载不干净基本集中在三个地方第一环境变量残留。很多人卸载 JDK 的时候只删了安装目录没有清理 JAVA_HOME、PATH、CLASSPATH 里的相关条目。残留的路径指向已经不存在的目录虽然不致命但会让排查过程非常头大。更麻烦的是你新装一个 JDK 之后旧的环境变量可能还是排在前面导致新装的根本用不上。第二Windows 注册表残留。Oracle 官方的 JDK 安装包会在注册表里写入大量项包括HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft、HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft里面记录了 JDK 版本号、安装路径、运行时设置。卸载程序一般会清理大部分但难免有漏网之鱼。注册表里的版本信息如果和新装的版本冲突有时候会影响部分依赖注册表查找 JDK 的软件比如 Eclipse 老版本。第三IDE 和构建工具缓存。IDEA、Eclipse、Maven、Gradle 这些工具会把 JDK 路径缓存到各自的配置里。卸载旧 JDK 后IDE 打开项目时提示找不到 JDK很多人以为 JDK 没装好其实 IDE 里配置的 SDK 路径还是旧地址。这个严格说不是系统层面的残留但它是卸载与安装这个话题里最常见的连带问题。明白了这三点你就知道为什么我一向主张卸载要按流程走安装要按逻辑来。接下来我按操作系统的角度把完整流程拆开讲。2. 动手卸载前先认清你电脑里装的是哪一种 JDK很多教程上来就让你删目录、清环境变量但忽略了最重要的一步先搞清楚你装的是什么发行版、用什么方式装的。不同发行版、不同安装方式卸载的手段和清理范围完全不一样。2.1 发行版差异Oracle JDK、OpenJDK、Temurin 的卸载区别JDK 的发行版非常多样常见的有 Oracle JDK、Oracle OpenJDK、Adoptium Temurin、Amazon Corretto、Azul Zulu 等。它们核心功能一致但安装方式和卸载逻辑有差别。发行版安装方式Windows卸载特点Oracle JDKexe 安装向导有正规卸载程序会清理注册表大部分内容Oracle OpenJDKzip 压缩包免安装删目录即可但环境变量手动配Temurinmsi 安装包有卸载程序支持静默卸载注册表清理较干净Correttomsi 或 rpm/deb同上Linux 下用包管理器管理Zulumsi 或 tar.gz同上判断自己装的是哪种最简单的方法看 JDK 安装目录下的文件结构和版权声明文件。Oracle JDK 的目录名一般是jdk-17、jdk1.8.0_202这种Temurin 的目录名一般是jdk-17.0.58这种带构建号的格式。另外执行java -version的时候输出里会带上发行版信息。macOS 上更简单打开终端执行/usr/libexec/java_home -V它会列出系统里所有 JDK 的完整路径和版本同时会标注 VM vendor也就是发行版厂商。有了这个清单你就知道系统里装了哪些 JDK。2.2 安装方式差异安装包和压缩包的卸载思路完全不同比发行版更关键的变量是安装方式。用安装包exe、msi、dmg、pkg、rpm、deb安装的 JDK一般会注册到系统的程序管理机制里。卸载的时候你应该走正规途径Windows 的设置-应用、macOS 的访达-应用程序-卸载、Linux 的包管理器。这么做的好处是系统自动帮你清理注册表项或包管理器的元数据。用压缩包zip、tar.gz解压得到的 JDK本质上就是一个绿色软件。它不注册到系统卸载方式就是直接删目录简单粗暴。但问题是这种 JDK 的所有配置环境变量都是你手动加的删目录之前如果没有先清理环境变量删完之后 PATH 里会出现一个死路径。所以每次卸载前我建议你先花两分钟回答三个问题这个 JDK 是安装包装的还是压缩包解压的有没有给这个 JDK 单独设置过 JAVA_HOME有哪些 IDE 或构建工具正在引用它回答完这三个问题再进入具体的卸载操作你的心里就有谱了。2.3 Windows、macOS、Linux 各自的 JDK 安装位置速查知道 JDK 装在哪里是清理残留的第一步。三系统默认位置如下WindowsC:\Program Files\Java\Oracle JDK 默认、C:\Program Files\Eclipse Adoptium\Temurin 默认、C:\Program Files\Amazon Corretto\Corretto 默认macOS/Library/Java/JavaVirtualMachines/系统级、~/Library/Java/JavaVirtualMachines/用户级Linux/usr/lib/jvm/Debian/Ubuntu 下 OpenJDK 默认集中在这个目录、/opt/java/部分发行版或手动安装的位置记住这些位置卸载的时候逐一检查基本不会漏。3. Windows 下的完整卸载流程从程序列表到注册表残留清理Windows 是 JDK 问题重灾区因为它的环境变量、注册表机制让卸载不干净的概率大大增加。下面这套流程是我在实际操作中总结出来的适用于 Windows 10 和 Windows 11。3.1 第一步通过正规途径卸载已注册的 JDK打开设置-应用-已安装的应用在搜索框里输入 Java 或 JDK你会看到类似Java(TM) SE Development Kit 17这样的条目。点击卸载按向导走完。这里有一个容易被忽略的细节Oracle JDK 的安装器可能会同时装 JDK 和 JRE它们是两个独立的条目。比如你装 JDK 8 的时候系统里可能有一个Java SE Development Kit 8和一个Java 8 UpdateJRE。卸载的时候如果 JRE 已经没用了建议一并卸掉不然它会在 PATH 里保留一个javapath入口继续干扰你后续的 Java 环境。如果你安装的是 msi 格式的 Temurin 或 Corretto卸载程序同样在已安装的应用里。个别 msi 安装包还支持静默卸载msiexec /x {产品GUID} /qn产品 GUID 可以通过Get-Package或注册表查到但对普通用户来说在图形界面里点卸载就足够了没必要折腾静默参数。3.2 第二步清理环境变量重点是 PATH 里的 java 路径卸载程序不会帮你清理环境变量这一步必须手动完成。打开系统属性-高级-环境变量分别检查用户变量和系统变量JAVA_HOME如果指向已卸载的 JDK 路径直接删除整个变量或者等新 JDK 装好后再改路径。PATH逐条检查把包含bin的 Java 相关路径删掉。常见需要删除的条目包括C:\Program Files\Java\jdk1.8.0_202\binC:\Program Files\Common Files\Oracle\Java\javapathC:\Program Files\Eclipse Adoptium\jdk-17.0.5.8-hotspot\binCLASSPATH这个变量在 JDK 9 之后官方已经不再推荐使用但很多老教程还在教人配。如果里面存的是.jar路径卸载 JDK 后相关路径自然失效建议一并清掉。清理 PATH 的坑在于PATH 是分用户变量和系统变量的两处都要看。我见过不少案例是系统变量里残留旧路径而用户只检查了用户变量导致清理不干净。另一个经典坑在编辑环境变量窗口上移下移调整顺序之后一定要点确定而且要把所有打开的属性窗口全部关闭。环境变量的生效是一次性读取机制——新开的程序会自动读到新值但已经打开着的 cmd 窗口、IDE 里缓存的旧值不会自动刷新。所以修改完环境变量必须开新的终端窗口验证。3.3 第三步注册表清理动手前先备份说句实在话大多数情况下你不碰注册表系统也不会出问题。注册表残留的主要影响是某些软件比如老版 Eclipse 的 Oomph 安装器通过注册表查找 JDK 版本时会读到旧版本号导致识别异常。如果你确定要清理按WinR输入regedit打开注册表编辑器定位到以下位置逐一检查HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft HKEY_CURRENT_USER\SOFTWARE\JavaSoftJavaSoft下面可能包含JDK、JRE、Java Development Kit等子键每个子键里有一个JavaHome字符串值指向安装路径。卸载后如果路径已经不存在了就可以删除对应的子键。强烈建议动注册表之前先右键导出JavaSoft整个项做备份。这年头谁都不保证手不会抖删错了还能一键还原。另外清理注册表之后不需要立即重启但注销或重启一次是最稳妥的可以确保所有系统级组件重新读取配置。3.4 第四步残留目录扫描前面说了 JDK 的默认安装目录卸载后顺手检查一下这些目录是否还残留在磁盘上C:\Program Files\Java\C:\Program Files\Common Files\Oracle\Java\C:\Program Files\Eclipse Adoptium\C:\Program Files\Amazon Corretto\C:\Users\用户名\.jdks\这是 IDEA 默认的 JDK 下载目录很多人装完 IDE 选项里的 JDK 会放这里C:\Users\用户名\.java\如果有残留目录直接删除。注意C:\Program Files\Common Files\Oracle\Java\里面可能除了javapath还有Updater等组件如果你的 JDK 卸载掉了整个 Oracle Java 公共目录一般都可以清掉。到这里Windows 的卸载流程就走完了。验证是否卸载干净新开 cmd 执行java -version如果提示不是内部或外部命令说明清理干净了。如果还能显示版本再用where java看路径继续排查剩余残留。4. JDK 安装的正确姿势版本选型、下载渠道与两种安装方式卸载完成接下来就是安装了。这一步的核心决策有三个装哪个版本、从哪里下载、用哪种方式安装。我把这三件事的底层逻辑拆开讲透。4.1 版本选型为什么说 JDK 17 是当前最稳妥的选择从热搜词里能看到很多人搜jdk 17下载jdk降级到17这非常贴合当前 Java 生态的真实状态。JDK 17 是目前生产环境最主流的 LTS长期支持版本。LTS 的含义是 Oracle 会持续提供多年免费的安全补丁和更新。目前常见的 LTS 版本有 8、11、17、21。其中 8 虽然还在被大量老项目使用但它已经很老了新项目不建议再入坑21 是最新 LTS功能很全但不少第三方框架对它的兼容还在磨合期17 处于一个非常均衡的位置——资源和框架兼容性成熟Spring Boot 3 和主流微服务框架都完美支持。至于很多人搜jdk降级到17通常是因为公司项目从 21 或 24 回退到 17或者团队统一 Java 版本时以 17 为基准。这也侧面说明 17 在行业里的接受度极高。选版本的另一个考量是位数。现在几乎所有主流平台都已经完全过渡到 64 位版本Windows、macOS、Linux 都直接下载 x64或 ARM 架构对应版本就行不用再纠结 32 位因为官方已经不再发布 32 位 JDK 了。4.2 下载渠道官网为主镜像站为辅但要会校验JDK 的下载渠道直接决定了你安不安全、会不会白折腾。我的建议优先级如下第一选择是官方渠道。Oracle JDK 的下载页面在甲骨文官网的 Software Downloads 区域你可以直接搜索Java SE Downloads。Oracle JDK 17 及以上版本提供免费下载包括商业使用场景条件是遵循 Oracle 的 NFTC 协议。Adoptium 的 Temurin 发行版在它的官网下载页面有各平台、各架构的 msi、tar.gz、zip 包也是官方渠道完全开源免费。第二选择是镜像站。很多人搜jdk镜像网站一般是因为官方页面下载不方便或速度慢。使用镜像站没有问题但一定要选择一个有公信力的站点比如国内高校的软件镜像站、大型云服务商的软件源。下载完之后必须校验哈希值——在文件列表里找到对应的.sha256文件然后用 PowerShell 执行Get-FileHash .\jdk-17_windows-x64_bin.zip -Algorithm SHA256对比输出的哈希值是否和官方或镜像站公布的 SHA256 一致。这一步是为了防止下载文件被篡改或损坏。强烈不建议去那种来路不明的下载站点进去全是高速下载按钮的站点下载器捆绑垃圾软件的事这几年一直没断过。JDK 是开发工具链里最底层的组件你要为它被捆绑的东西付出远超想象的维护成本。4.3 两种安装方式msi 安装包和 zip 免安装到底怎么选Windows 下的安装方式基本分为两类msi/exe 安装包、zip 压缩包免安装版。两者的对比如下对比项msi/exe 安装包zip 免安装版安装过程走向导自动写注册表解压即用无注册表卸载难度有正规卸载入口删目录即完成卸载环境变量部分安装包自动配 PATH必须手动配置系统集成注册 Oracle Java 公共路径无系统级集成适合场景新手、不想手写配置老手、需要多版本并存如果你只是需要一个稳定可用的 Java 环境我推荐 msi 安装包比如 Adoptium 的 msi原因有三卸载干净、注册表信息完整、和 Windows 应用体系兼容性好。但如果你需要同时维护多个 JDK 版本、频繁切换zip 免安装版反而更适合——你把几个 JDK 解压到固定目录用环境变量随时切换互不干扰。还有一种折中方案用 msi 装你日常的主力版本再去官网下载 zip 版备用版本放到其他目录。主力版本走正规流程备用版本需要时切换 JAVA_HOME平时完全不干扰。4.4 Windows 下 msi 与 zip 的详细安装步骤msi 安装包流程双击 msi 文件一路点 Next。选择安装功能和安装路径。默认功能选择完整版路径建议不要含中文和空格比如C:\Program Files\Java\jdk-17。安装完成后到设置-系统-环境变量配置 JAVA_HOME 和 PATH。新建系统变量JAVA_HOME值为安装路径比如C:\Program Files\Java\jdk-17。编辑 PATH新增一行%JAVA_HOME%\bin。新开 cmd输入java -version和javac -version验证。zip 免安装版流程下载 zip 包比如jdk-17_windows-x64_bin.zip。解压到固定目录比如D:\dev\jdk-17。记住这个路径后续配置全靠它。配置 JAVA_HOME 指向D:\dev\jdk-17。PATH 新增%JAVA_HOME%\bin。验证同一套命令。你可能注意到两种方式的环境变量配置步骤完全一样。原因很简单msi 只是帮你做了解压到目录注册系统这两件事环境变量最终还是要靠 JAVA_HOME/PATH 这套机制让命令行找到 java。理解这一点你对 JDK 安装的认识就超过大多数人了。4.5 macOS 和 Linux 安装速览macOS 安装 JDK 最省心的一种方式是用 Homebrewbrew install temurin17装完不用配环境变量Homebrew 会把java软链到/opt/homebrew/bin/下。如果你想装多个版本可以安装完之后用/usr/libexec/java_home -V查看用export JAVA_HOME$(/usr/libexec/java_home -v 17)临时切换。LinuxUbuntu/Debian 系用 aptsudo apt update sudo apt install openjdk-17-jdk装完后 JDK 在/usr/lib/jvm/目录下用update-alternatives --config java可以切换默认版本。如果从官网下载 tar.gz 包手动安装流程和 Windows 的 zip 版类似解压到/usr/local/或/opt/然后在/etc/profile或用户~/.bashrc里导出JAVA_HOME和PATHexport JAVA_HOME/usr/local/jdk-17 export PATH$JAVA_HOME/bin:$PATH最后执行source ~/.bashrc让配置立即生效。5. 环境变量不是玄学JAVA_HOME、PATH、CLASSPATH 的职责边界与失败排查jdk环境变量配置失败几乎是每个 Java 新手必经的坎。这块网上教程一大堆但大部分只告诉你这么配不告诉你为什么这么配。不理解底层逻辑你永远都在背命令遇到报错就懵。5.1 三个变量的真实职责JAVA_HOME是一个约定的环境变量名它告诉其他工具JDK 安装在哪个目录。IDEA、Maven、Tomcat 等工具启动时会读取 JAVA_HOME 来定位 JDK。为什么要单独设这个变量因为 PATH 里的路径是给操作系统找命令用的而很多软件需要的是 JDK 的根目录不是 bin 目录。通过 JAVA_HOME 中转一层你换版本时只需要改 JAVA_HOME 这一个变量PATH 里始终写%JAVA_HOME%\bin即可自动跟随。PATH是操作系统搜索可执行文件的路径列表。你在 cmd 里敲java系统会按 PATH 里的顺序依次找java.exe找到就用找不到就报不是内部或外部命令。所以 PATH 里要有%JAVA_HOME%\bin意思就是去 JDK 的 bin 目录里找 java 命令。CLASSPATH是 Java 平台查找类的路径列表。JDK 5 之后 JVM 会自动定位核心类库CLASSPATH 已经不是必需的了。我见过很多人按古早教程配了一长串 CLASSPATH配完之后各种意想不到的类冲突。我的建议是JDK 9 及以上版本不要把 CLASSPATH 写进系统变量。真要指定某个 jar 包时用-cp参数临时指定即可。5.2 环境变量配置失败的完整排查链路如果你配完发现java -version报错或版本不对按下面的链路一步步走比重新装卸有效率得多。第一步确认 JAVA_HOME 是否指向正确的目录。新开 cmd 执行echo %JAVA_HOME%如果输出为空说明 JAVA_HOME 没生效检查是否写错了变量名英文大小写无所谓但别带空格或者没有点确定关闭窗口。第二步确认 PATH 里有没有%JAVA_HOME%\bin。执行echo %PATH%看输出里有没有C:\Program Files\Java\jdk-17\bin%JAVA_HOME% 会被展开成实际路径。如果没有去环境变量编辑器检查 PATH 列表。一个常见问题PATH 里写的是绝对路径而不是%JAVA_HOME%比如C:\Program Files\Java\jdk-17\bin。这种写法本身能工作但如果你下次换了 JDK 版本PATH 里的绝对路径不会自动跟着 JAVA_HOME 变化就会出问题。第三步检查路径优先级。执行where java看输出的第一行是什么。如果第一行是C:\Program Files\Common Files\Oracle\Java\javapath\java.exe说明公共 javapath 抢占了优先级。最简单的处理办法是按前面说的卸载流程把公共 javapath 从 PATH 里移出或者把 JAVA_HOME 相关的 bin 路径上移到最高优先级。cmd 对 PATH 的处理是从左到右先到先用所以想让你自己装的 JDK 生效就必须保证它的 bin 排在所有其他 java 相关路径之前。第四步确认 java 命令和 javac 命令来自同一个 JDK。这是最阴险的问题java -version显示 17javac -version显示 1.8。原因通常是 PATH 里同时存在多个 JDK 的 bin 目录而 java 和 javac 被不同目录提供了。比如先有一个 JDK 8 的 bin 路径又有一个 JDK 17 的 bin 路径java被前一个找到javac却因为某种原因被后一个找到。解决方式就是统一 PATH 顺序保留一个 JDK 的 bin 在最前面。第五步验证工具链一致性。配置完成后的终极验证不是只跑一个命令而是要连续跑java -version javac -version where java where javac确保 java 和 javac 的版本一致、路径都指向 JAVA_HOME 下的 bin。我自己在每次装完新 JDK 或切换版本后都会用这四连验证三十秒搞定省掉之后无数麻烦。5.3 老版本 JDK 在 Win11 上的环境设置注意点热搜词里的win11 jdk 1.6环境设置属于一个比较特殊的诉求因为 JDK 1.6 是 2006 年发布的古董版本Windows 11 对它的兼容性确实是个问题。首先JDK 1.6 官方支持的最高 Windows 版本是 Windows 7在 Win11 上运行会遇到各种坑比如命令窗口可能无法正常显示中文、某些 API 调用的行为不一致。其次Win11 默认环境下 JDK 1.6 的目录路径如果带空格或特殊字符可能会引发奇怪的问题。如果你真的需要在 Win11 上用 JDK 1.6我的建议是优先用虚拟机装一个 Windows 7 或 Windows 10 的镜像来跑老项目而不是强行在 Win11 上折腾。如果只能在本机跑安装时选择以管理员身份运行安装路径避开C:\Program Files这种带空格的目录改用C:\jdk1.6。话说回来JDK 1.6 对应的 Java 生态已经非常古老了除非是维护远古遗留项目否则不建议在这个版本上花时间。6. 多版本并存的版本管理实战降级、切换与遗忘的坑现在很多开发者的电脑上都有不止一个 JDK有的是因为不同项目要求不同版本有的是因为手痒装了个新版试试水结果公司项目还跑在老版本上。多版本并存不是问题问题是怎么管理它们让切换变得无痛。6.1 为什么需要降级到 17项目依赖的版本约束逻辑热搜词里jdk降级到17搜索热度不低说明这不是个别需求。降级的原因通常很现实项目是用 JDK 17 编译的但本地环境是 21 或更新的版本编译时可能因为某些 API 变更而报错或者公司的 CI/CD 流水线锁定了 17本地开发必须与其保持一致。这里我要多说一句新版本的 JDK 并不总是向下兼容的。Oracle 对 JDK 的兼容性有一套严格的规范但一些非公开 API、内部实现会随着版本更新而变化。比如 JDK 9 引入了模块系统rt.jar被拆分很多依赖rt.jar的老框架直接崩JDK 17 又加强了对强封装内部 API 的访问限制反射操作某些内部类会抛异常。所以生产项目锁版本不是守旧而是稳定性的需要。降级操作的本身不复杂本质上就是卸载新 JDK 装上旧 JDK或者新增一个旧版 JDK 并把 JAVA_HOME 指过去。但很多人降级后项目还是运行异常原因往往是这里——IDE 和构建工具里缓存的 JDK 路径还是旧的。6.2 Windows 下的多版本切换实操我自己的方案是在D:\dev\下建立多个 JDK 目录每个版本一个文件夹比如D:\dev\jdk8、D:\dev\jdk17、D:\dev\jdk21。然后 JAVA_HOME 指向当前我需要作为默认的那一个。切换版本时只需要修改 JAVA_HOME 这一个变量set JAVA_HOMED:\dev\jdk17如果你想临时切换只对当前 cmd 会话生效不用去改系统变量直接在 cmd 里执行上面的 set 命令就行。想要永久切换就去环境变量编辑器里改 JAVA_HOME 的持久值。这个方案的优点是极简、透明、随时可逆没有任何第三方向导的额外开销。缺点是每次切换都要手动操作而且如果忘记切换可能带着错误的 JAVA_HOME 启动 IDE。如果你想要一个更自动化的版本管理工具可以试试 SDKMAN。虽然它最常用在 Linux/macOS 上但 Git Bash 环境里也能跑你可以在终端里用sdk list java查看可安装版本用sdk install java 17.0.5-tem安装指定版本用sdk default java 17.0.5-tem设定默认版本。用过 Node.js 的 nvm 的同学上手 SDKMAN 会非常顺手。6.3 Linux 下的 alternatives 机制Linux 用户在切换 JDK 版本时有一个 Windows 没有的利器update-alternatives。它是 Debian/Ubuntu 系统管理可执行文件软链接的工具。安装多个 OpenJDK 后执行sudo update-alternatives --config java系统会列出所有已安装的 java 可执行文件输入数字即可切换默认版本。javac 也需要单独切换sudo update-alternatives --config javac这个机制的好处是你不用手动去改 PATH系统自动维护好/usr/bin/java的软链接。但注意update-alternatives 只管理了 /usr/bin 下的命令入口JAVA_HOME 它不负责。所以你还得手动把 JAVA_HOME 设置到对应的 JDK 目录或者用一个小技巧让 JAVA_HOME 指向一个固定的路径然后每次切换时更新这个路径下的软链接。6.4 三个我踩过的多版本教训写出来提醒你多版本管理看起来简单实际坑不少。拿我自己的经历来说第一个教训PATH 里写入过具体版本号的路径。以前我图省事直接在 PATH 里写死C:\Program Files\Java\jdk-17\bin后来装了 JDK 21把 JAVA_HOME 指过去java -version还是 17。排查了半天最后发现 PATH 里那个绝对路径优先级高于%JAVA_HOME%那一条。从那以后我再也不在 PATH 里写绝对路径统一用%JAVA_HOME%\bin。第二个教训IDE 里的 Project SDK 不会自动跟随 JAVA_HOME 变化。IntelliJ IDEA 默认会读取系统 JAVA_HOME 作为 JVM 运行环境但每个项目的 Project SDK 是独立记忆的。你切换了 JAVA_HOME旧项目打开后依然用的是它记忆的旧 JDK 路径。如果那个路径已经删了IDE 就会提示SDK 未定义。这不是环境变量的问题是 IDE 的配置问题。做法是打开 File-Project Structure-Project把 SDK 改成你想要的新版本然后在 Settings-Build Tools 里检查 Gradle/Maven 的 Java 版本设置。第三个教训命令行窗口的缓存残留。这个其实前面提过但值得再强调修改环境变量后已经打开的所有 cmd、PowerShell、IDE 内部终端读到的都还是旧值。你的配置明明改对了但终端里输出还是旧版本。解决办法无他全部关掉重新开。Windows 系统修改环境变量后还有一种极端情况是某些系统服务比如以服务方式运行的 Tomcat不会重新读取环境变量需要重启服务或重启电脑才能生效。7. 写在最后的实用建议围绕JDK 的卸载与安装这个话题把该讲的都讲了。最后再分享几条我个人在实际操作中沉淀下来的习惯算不上什么高深技巧但确实帮我省了很多折腾时间。第一永远保留 JDK 的原始安装包或压缩包。不要卸载完就删掉安装包因为你可能需要降级回去。我在D:\dev\downloads\下专门放了一个 jdk 安装包目录下载时带上版本号比如jdk-17.0.5_windows-x64_bin.zip、jdk1.8.0_202_windows-x64_bin.exe要用时直接解压即可。第二装新 JDK 之前先看一眼现在的环境变量长什么样。把当前 JAVA_HOME、PATH 里的 Java 相关项截图保存。这样即使操作过程中把配置搞乱了也能对照截图快速恢复省去在报错信息里猜来猜去的时间。第三每次配置完环境变量用同一套验证命令形成肌肉记忆java -version、javac -version、where java、where javac四连跑。这套验证我已经坚持了好几年累计下来真的帮我避免了好多次以为配好了结果还是不对的尴尬。JDK 的卸载与安装就是这么一回事——原理层面懂了操作层面细心踩坑概率会大幅降低。如果你在操作过程中遇到什么奇怪的异常欢迎在评论区描述你的系统环境、装了什么版本、做了什么操作我们可以一起推演排查。毕竟环境这种东西最怕的就是别人看不到细节、纯靠猜。
阅读完成 · 觉得有帮助？
