陆牙1. 为何你的开发机里总是一堆JDK版本在打架
先说个场景，我相信绝大多数Java开发者都经历过。你手上同时维护着两三个项目，老项目跑在JDK 8上，Spring Boot 2.x那套，动不得；新项目要用Spring Boot 3，逼着你上JDK 17；偶尔还有个老旧的Gradle构建脚本，连--release参数都不认识，JDK 8和JDK 17它都嫌不对。你怎么办？装两个JDK，然后每次切换项目之前，手动去系统环境变量里改JAVA_HOME，改完还得重新开终端，敲一句java -version验一下，确认没改错。
这种操作一次两次还好，一个月下来你就烦了。尤其是有一次我为了切JDK版本，手滑把Path变量里其他内容也改了，导致终端里连mvn命令都找不到了，整整排查了半个多小时，最后发现是环境变量里一个分号被误删。那一刻我就下定决心，必须找一个正经的多版本管理工具来干这件事。
这就是我这次要详细说的 JDK多版本管理工具jvms。它的定位非常纯粹：让你在同一个操作系统上安装多个JDK版本，并且随时一键切换，彻底告别手动修改环境变量的时代。除了jvms，生态里也有SDKMAN这类老牌工具，但jvms在Windows平台上有自己的优势，后面我会专门做对比。如果你手头正好为"同事要我JDK降级到17""项目构建找不到JDK""IDEA里配的JDK和终端对不上"这类问题焦头烂额，这篇文章可以帮你把整条链路打通。
适合读这篇文章的人，我总结了一下：刚入门Java、第一次被环境变量折磨的新手；在本机装了五六个JDK但从来没搞明白怎么管理的资深开发；还有需要在多个项目之间频繁切换JDK版本的维护型选手。前面两类读者，今天这篇文章应该能让你少走很多弯路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. jvms到底是什么，和手动改环境变量差在哪
2.1 核心原理：一个代理层搞定所有版本切换
jvms的工作机制，其实一句话就能说清楚：它在你系统里维护了一个"当前JDK"的指向，你执行jvms use命令的时候，它会把系统的JAVA_HOME和相关路径重新指向你选中的那个JDK目录，然后所有依赖JAVA_HOME的工具（Maven、Gradle、IDEA里的终端等）就都跟着走了。
这个思路和Node.js的nvm、Python的pyenv是同一个套路。你可以理解成：你的电脑里安装了很多个JDK实体，它们安安静静地躺在各自的目录里，平时互不打扰；jvms是那个站在前台的管理员，你喊一声"切换到JDK 17"，它立刻把门口的招牌（环境变量）换成JDK 17的地址。
和手动管理相比，差别是结构性。手动管理时，JAVA_HOME写死在系统属性里，你要修改就得打开系统设置，一层一层点进去，改完还要处理Path里可能存在的其他JDK残留路径。jvms管理时，JAVA_HOME指向的是一个由jvms动态维护的位置，你完全不需要关心真实JDK装在哪里，只用告诉jvms你想用哪个版本，剩下的事情它处理。
2.2 jvms、SDKMAN、手动管理三者的横向对比
很多人第一反应是，我用SDKMAN不就行了？确实，SDKMAN在macOS和Linux上非常好用，我周围不少同事都在用。但SDKMAN本身是为Unix-like系统设计的，在Windows上需要借助Git Bash或WSL才能跑，体验还是隔了一层。jvms的设计目标从一开始就覆盖Windows、macOS和Linux，对Windows用户友好得多。
| 对比维度 | jvms | SDKMAN | 手动管理 |
|---|---|---|---|
| Windows原生支持 | 好，直接命令行使用 | 需要Git Bash/WSL | 原生但繁琐 |
| 版本切换速度 | 快，秒级 | 快，秒级 | 慢，改环境变量+重开终端 |
| 多版本并行安装 | 支持 | 支持 | 自己下载解压也行 |
| 版本自动下载 | 支持，内置下载源 | 支持 | 自己上官网找 |
| 学习成本 | 低，命令少 | 低 | 无但易出错 |
| 对现有项目无侵入 | 是 | 是 | 是 |
这里多说一句，手动管理并不完全一无是处。如果你一年到头只需要一个JDK版本，装好之后基本不动，那手动装一次也无妨。但只要你有一个"JDK降级到17"或者"临时要用JDK 8跑一个老项目"的需求，手动管理的成本瞬间就上来了。jvms这类工具的价值，正是在这种频率不高但每次都很折腾的场景里体现得最充分。
3. jvms从零安装到初始化，Windows和macOS两条路都走一遍
3.1 Windows下的安装步骤：比想象中简单
先说Windows，这也是jvms覆盖最用力的平台。安装方式大致分两种：用包管理器，或者直接下载可执行文件。
如果你电脑里装了Scoop，一条命令就能搞定：
bash复制scoop install jvms
如果用的是Chocolatey，也可以试试：
bash复制choco install jvms
如果这两个包管理器都没有，那就去jvms的GitHub Releases页面下载对应的Windows安装包。下载下来解压之后，把jvms所在目录加到系统Path里，然后在新的终端窗口里执行：
bash复制jvms --version
能输出版本号就说明装好了。这里的坑点在于，如果你是用安装包方式装的，一定记得关掉所有旧终端窗口再开新的，否则Path环境变量不会刷新。我刚开始就因为这个，一度以为安装失败了。
3.2 macOS和Linux下的安装：一行脚本搞定
macOS和Linux的安装更直接，官方提供了一行脚本。执行：
bash复制curl -fsSL https://raw.githubusercontent.com/.../install.sh | bash
装完之后，脚本通常会提示你把jvms的初始化代码加到shell配置里（比如.bashrc或.zshrc）。这一步非常重要，因为jvms需要在shell启动时设置一些环境变量，不执行的话，jvms use切换完版本不会对当前终端生效。
bash复制# 在 ~/.zshrc 或 ~/.bashrc 中添加
export JVMS_HOME="$HOME/.jvms"
export PATH="$JVMS_HOME/bin:$PATH"
3.3 初始化阶段最容易踩的两个坑
第一个坑，装完了但命令找不到。这种问题九成是Path没配好，或者终端没重开。解决方法就是反复确认Path包含jvms的bin目录，然后重开终端。
第二个坑，执行jvms use之后，java -version还是原来的版本。这个问题的根因通常是你的Path里，JDK原本的路径排在jvms前面。比如你之前手动装过JDK，把C:\Program Files\Java\jdk-17加到了Path里，这个路径在jvms的bin路径前面，系统先找到了旧JDK。解决办法是把jvms的路径调整到Path最前面，或者在初始化脚本中显式覆盖JAVA_HOME。
有个判断技巧可以分享给你们：当切换版本不生效时，先执行where java（Windows）或which -a java（macOS/Linux）看系统到底找到了几个java。如果列出来的第一个路径不是jvms管理的那个，基本上就是Path顺序问题。这个排查思路，对后面理解IDEA里的版本冲突也有帮助。
4. 高频操作逐项拆解：安装、切换、删除、设默认
4.1 安装指定JDK版本：jvms install的正确用法
jvms的核心命令集非常精简，第一个要掌握的是jvms install。它的作用是下载并安装指定版本的JDK，版本号可以用完整版，也可以只写主版本号。
bash复制# 安装JDK 17
jvms install 17
# 安装JDK 8
jvms install 8
# 安装指定小版本
jvms install 17.0.9
这里有个非常值得说的设计：jvms会从内置的下载源拉取对应发行版的JDK，省去了你自己去官网找历史版本下载的功夫。我用它安装过JDK 8和JDK 17，整个过程只需要等待下载完成，不需要解压、不需要手动复制目录、不需要配置什么，装完就能用。对比我以前去Oracle官网下载JDK 8还要登录账号，这个体验是断崖式提升。
如果你想确认当前有哪些版本可以安装，可以执行：
bash复制jvms ls-remote
它会列出所有可用版本。这里提醒一句，如果你公司网络访问外网较慢，下载耗时可能比较长，耐心等就行。实在不行，可以考虑使用镜像源，后面进阶部分我会讲到。
4.2 切换当前版本：jvms use背后的"魔法"
装好之后，核心操作就是切换。命令如下：
bash复制# 切换到JDK 17
jvms use 17
# 切换回JDK 8
jvms use 8
此时你在同一个终端里再执行：
bash复制java -version
javac -version
输出的就是切换后的版本信息了。整个过程秒级完成，不需要重启终端，不需要重新登录系统，也不需要去系统设置里点来点去。
我试过在一个终端会话里来回切换JDK 8和JDK 17，反复执行jvms use 8和jvms use 17，每次都立即生效，没有一次失败。这个特性在同时构建老项目和新项目时尤其珍贵，以前构建完老项目再构建新项目，我会先改环境变量，再开新终端，现在直接在项目目录下执行一条命令就行。
4.3 查看已安装版本：一目了然的状态清单
bash复制jvms ls
# 或者
jvms list
执行后，它会列出所有已安装的JDK版本，并标出当前正在使用的版本。前几年我开发机上装了好几个JDK，因为时间久远，连自己都记不清装了哪些、分别装在哪个目录。用jvms之后，所有的版本都统一管起来了，一条命令就能看到全部状态，这一点对于有强迫症的人来说非常解压。
4.4 删除旧版本与设置全局默认：别让垃圾版本堆积
JDK版本更新的速度很快，过一两年你可能会发现某个版本已经没人用了，留着占磁盘空间。这时候执行：
bash复制jvms remove 11
就能把对应版本从磁盘上清理掉。这个命令比手动去卸载JDK要干净得多，因为jvms卸载时会同时处理符号链接和环境变量里的残留项。
设置默认版本也很简单：
bash复制jvms alias default 17
设置完之后，每次新开的终端会自动使用JDK 17，省得每次都手动use。我之前没有设置默认版本，结果某一天重开终端后java -version突然变成了JDK 8，当时愣了一下，才想起来前一天切过版本。设置好默认版本之后，这种"灵异事件"再也没出现过。
5. 和IntelliJ IDEA配合时，版本不一致的问题这样解决
5.1 IDEA里的Project Structure配置
很多同学会在IDEA里遇到一种情况：终端里java -version显示JDK 17，但IDEA里的项目却报编译错误，提示"java: invalid source release"或者"Error: java: JDK isn't specified for module"。这种问题大概率是IDEA的Project SDK没选对。
IDEA本身不直接读取你系统里最新的JAVA_HOME，它维护了一套自己的SDK列表。虽然IDEA会自动扫描系统里常见的JDK路径，但如果你用jvms管理版本，IDEA扫描到的可能是jvms目录下的某个具体版本，而不是你当前切换的那个。
解决办法是手动在IDEA里指定SDK：
- 打开
File->Project Structure（快捷键Ctrl+Alt+Shift+S）。 - 在
Project标签页下，把SDK设为对应的JDK版本。 - 在
Module标签页下，把模块的Language level和SDK也做对应调整。
这里有个更稳妥的操作：直接用jvms的当前JDK路径，把它作为IDEA的SDK。你可以在终端里执行：
bash复制jvms current
它会输出当前JDK的实际路径。把这个路径填到IDEA的SDK配置里就行。不过要注意，如果你在终端里用jvms use切换了版本，IDEA里已经打开的SDK配置不会自动跟着变，需要重新设置一次。
5.2 终端里java -version与IDEA不一致：别慌，这是正常的
还有一种情况，你在IDEA的终端（Terminal）面板里执行java -version，输出和系统终端里一模一样，因为IDEA终端本质上就是系统shell。但IDEA内部构建用的SDK，可能和你终端里JAVA_HOME指向的版本不一致。这就造成了一个现象：终端里是JDK 17，IDEA Build却用的JDK 8，编译报错奇奇怪怪。
排查思路其实很简单：在IDEA里看File -> Project Structure -> Project下的SDK是什么版本，再看Build Tools里Maven或Gradle的JAVA_HOME配置是什么版本。如果两个地方不一致，以实际需要编译的JDK版本为准，二选一改掉。
我个人习惯是，在自己的开发机上，把IDEA的Project SDK始终设为jvms管理的JDK 17，构建工具如果用Maven，就在.mvn/jvm.config里不要额外指定JAVA_HOME；Gradle的话，在gradle.properties里不设置org.gradle.java.home。这样所有的构建行为都跟随jvms的当前切换，逻辑最清晰。
5.3 实际操作中遇到过一次"找不到JDK"的完整排查过程
有一阵子我的IDEA、Maven、终端三方"集体失联"，每次构建都报"Unable to locate a Java Runtime"。当时我的第一反应是jvms没接管好。排查了一圈，最后发现问题出在Windows的注册表残留上——我之前手动装过一个JDK，卸载时没卸干净，注册表里还留着旧版本的信息，导致系统层面判断"JDK不存在"。
这个问题的定位过程值得说说。第一次排查，我执行java -version，终端直接报命令不存在，说明Path里连java都找不到了。第二次查看JAVA_HOME，发现它指向的是一个已经删除的目录。这个就很有意思了，明明jvms已经接管了JAVA_HOME，为什么还会指向一个不存在的目录？原因在于我之前在系统环境变量里手动设置过JAVA_HOME为某个固定路径，而jvms的初始化脚本是在shell配置里覆盖JAVA_HOME的，这两者之间存在优先级冲突。
解决办法很简单：把系统环境变量里的JAVA_HOME清掉，完全交给jvms来管理。设置完之后，重新打开终端，执行jvms use 17，再验证java -version，一切恢复正常。这次排查让我彻底明白了jvms和其他手动配置之间的"管辖权"边界：凡是交给工具管理的变量，就不要在系统层面重复设置，否则就会互相打架。
6. 进阶玩法：脚本初始化、CI缓存、跨机器同步
6.1 新环境一条命令初始化：我是这么做的
如果你像我一样，一年要配好几次新电脑或新的开发环境，手动安装JDK、配置环境变量、再装jvms这一套流程虽然不复杂，但要重复很多遍，非常浪费时间。我现在的做法是写了一个简单的初始化脚本，放在自己的配置仓库里。
以Windows为例，脚本大致长这样：
bash复制# init-jvms.bat
scoop install jvms
jvms install 8
jvms install 17
jvms alias default 17
echo "JDK 8 and JDK 17 installed, default set to 17"
macOS/Linux下，对应脚本就换一下安装方式即可。这样每台新机器只需要执行一次，就自动装好两个最常用的JDK版本并设好默认值。有了这个脚本，我再也没有手动去Oracle官网下载过JDK，团队里新成员入职，发一个脚本让他们自己跑，环境问题基本不用我远程指导。
6.2 在CI流水线里切换JDK版本：不止是本地开发需要
本地开发环境用jvms管好之后，很多人会忽略CI（持续集成）环境的JDK管理。CI服务器上的JDK版本如果不和本地一致，很容易出现"本地能构建，CI上报错"的情况。
如果你们的CI跑在自建服务器上，也可以安装jvms，然后在流水线脚本里根据项目需求执行：
bash复制jvms install 17
jvms use 17
mvn clean package
这样CI和本地用的是同样的管理逻辑，JDK版本的一致性会好很多。我用这个方法解决过团队里一个非常头疼的问题：有同事在本地用JDK 8编译，反编译反编译到别的环境，一跑就ClassNotFoundException，后来统一在CI里通过jvms固定JDK版本，这种问题就再也没出现过。
当然，如果你的CI是容器化的（比如Docker），那更推荐直接在镜像里固定JDK版本，jvms的使用场景还是在"一台机器上需要多个版本共存"时比较顺手。
6.3 多台机器同步jvms配置的小技巧
最后分享一个省事的技巧。jvms的配置和已安装版本信息，一般存在于~/.jvms目录下。如果你不想让每台机器都重新下载一遍所有JDK，可以把这个目录整体同步到新机器，或者放到云盘里。不过要提醒一下，不同操作系统的JDK二进制不一定通用，跨平台同步前要确认好。
这里的正确做法是：只同步jvms的配置和版本清单，不直接同步JDK二进制文件。具体操作是，在新机器上执行jvms ls-remote查看可用版本，然后用jvms install按需安装。这样虽然多花几分钟下载时间，但避免了二进制不兼容带来的大坑。
7. 关于底层原理和版本差异化，多说两句
7.1 jvms和JVM、JRE、JDK三者之间的边界
很多新手容易混淆JDK、JRE和JVM这三个概念，这里顺手给还不清楚的读者理一理。
- JVM（Java Virtual Machine）：Java虚拟机，负责把字节码解释/编译成机器码，是运行Java程序的底层引擎。
- JRE（Java Runtime Environment）：Java运行环境，包含JVM和Java核心类库，只能运行Java程序，不能编写和编译。
- JDK（Java Development Kit）：Java开发工具包，包含JRE、编译器
javac、调试工具、文档工具等，是Java开发者的核心工具包。
jvms管理的对象是JDK，也就是包含了编译器和运行环境的那一整个包。当你用jvms use切换版本时，切换的既包括运行Java程序用的JRE部分，也包括编译用的javac版本。这就是为什么切换之后，重新编译老项目可能会遇到"编译目标版本和运行时版本不匹配"的问题——你想要编译成JDK 8的class文件，但当前javac是JDK 17的，不加--release 8参数的话，编译产物可能用到JDK 17特有的API，放到JDK 8环境运行就会直接报错。
7.2 为什么我建议你尽量使用jvms而不是手动指定JAVA_HOME
我再补一个自己的体感结论。手动管理JAVA_HOME不是不能用，而是当你的项目数量超过两个、JDK版本超过两个的时候，人为出错率会指数级上升。大脑在"a项目用8，b项目用11，c项目用17"之间反复横跳，总有一天会忘记切版本，然后对着一个莫名其妙的编译错误发呆半小时。
jvms把"当前该用哪个JDK"这个状态显式化了，它不依赖你的记忆力。更关键的是，jvms use的切换是当前终端生效的，这意味着你可以在窗口A里用JDK 8，窗口B里用JDK 17，互不干扰。这在手动管理时代几乎做不到——你改一次环境变量，所有新开的终端就全变了。对需要并行处理多项目的开发场景来说，这种"隔离性"的价值怎么强调都不为过。
8. jvms使用中的几个避坑经验，都是从实操里总结出来的
8.1 升级jvms可能导致配置失效：先备份再用新版本
作为开源工具，jvms也在不断迭代。某次我升级了jvms，发现之前设置过的alias default 17没有生效，查了一下才知道新版本改了配置文件的存储格式。所以这里建议，升级前先看一眼Release Notes，如果有breaking change，提前确认一下自己有没有依赖旧的配置项。
如果你也在生产环境级别的开发机里大量使用jvms，建议升级前把~/.jvms目录整体备份一下，或者用系统的快照功能。虽然大概率用不上，但一旦出问题，恢复成本会低很多。
8.2 系统自带JDK和jvms托管JDK共存的"3条军规"
有些系统（比如macOS自带的/usr/bin/java，或者某些安装包自己带JDK）会和jvms托管JDK并存。这是最容易产生冲突的地方，总结三条军规供你们记住：
- 不要在系统环境变量里显式写死
JAVA_HOME，让jvms的初始化脚本接管。 - 不要把非jvms管理的JDK路径手动加到
Path里，尤其是加在jvms前面。 - 如果IDE或构建工具里单独指定了JDK路径，确保它指向jvms管理的版本，而不是系统自带的那个。
遵循这三条，你的开发环境会非常清爽。我自己早期就在macOS上吃过亏：系统自带Java 8，我又装了JDK 17，结果/usr/bin/java显示的版本和/usr/libexec/java_home -v 17显示的版本不一样，构建时好时坏。后来我干脆把系统自带的JDK从Path里拿掉，只保留jvms管理，世界一下就清净了。
8.3 一个极易忽略的命令行细节：执行完jvms use后务必验证
jvms use执行完之后，它会打印当前版本信息，按理说不需要再额外验证。但我仍然建议你们每次切换后执行一句java -version确认一下。原因在于，某些shell配置或IDEA项目配置会临时覆盖环境变量，可能出现jvms认为切换成功、实际当前终端却用了别的版本的情况。多敲一条命令的成本极低，但省去的是"改错版本导致的几十分钟排查"。
这里也分享一个批量验证的技巧。如果你是Windows PowerShell用户，可以执行：
bash复制jvms use 17; java -version; javac -version
一条命令完成切换和验证，效率和可靠性都兼顾了。
9. 最后的个人体会：工具要能沉淀成自己的工作流
前面讲了很多命令和操作，最后聊聊我自己的心得。jvms这类工具，它解决的不只是"切JDK版本"这一个点，它帮你把"开发环境管理"这件事收拢成了一个可重复、可脚本化、可迁移的流程。以前配一台新电脑，我会花一下午去官网找历史版本、下载、解压、配环境变量，然后祈祷不要出幺蛾子。现在有了jvms，一台新机器从装好系统到能跑起项目，压缩到了十几分钟内。
另外一个更深层的体会是：环境管理工具的价值，在于帮你在多个版本的矩阵里建立秩序。JDK版本只是其中一种，同理还有Node.js的nvm、Python的pyenv、Go的gvm。它们的共同思路都是，把"环境变量切换"从手动操作变成工具行为，让人把注意力集中在真正的代码和业务上。
如果你现在还在手动改JAVA_HOME，我真心建议你花十分钟装个jvms体验一下。第一次执行jvms use 17然后看到终端里java -version瞬间变化的那一刻，你就知道以前自己为了版本切换浪费了多少时间。有句话说得好，工具的终极目标不是让你多做点什么，而是让你不用做那些本就该被自动化的事情。jvms在我这里，确实做到了。