做 Java 开发的人尤其是工作在 Linux 环境下的基本都绕不开一个场景本机同时装着好几个 JDK老项目锁定在 JDK 8新项目要求 JDK 11 起步偶尔还要给特定环境编一份 JDK 17 的产物。每次换项目就去改 JAVA_HOME、改 PATH改完忘了 source终端里一堆 java -version 对不上测试环境一跑就是 UnsupportedClassVersionError。我先后试过 update-alternatives、手动改环境变量、jenv踩了一圈坑之后最后还是自己写了个轻量的 JDK 版本切换器。这篇文章把我的完整思路、脚本实现和排坑心得都整理出来需要的同学可以直接复制改路径省得再走一遍弯路。1. 为什么你需要一个 JDK 版本切换器1.1 多版本共存的真实场景很多人以为装个最新版 JDK 就一劳永逸了真实项目根本不是这么回事。老框架在 JDK 8 上跑得好好的换到 17 直接给你报模块访问错误反过来你在代码里用了 record 或者 switch 表达式这种新语法切回 8 连编译都过不了。还有一种更磨人的情况团队里不同服务的目标运行时版本不一致本地开发和线上部署必须严格对应不然打包出来没问题跑到服务器上启动就报错。我自己手上就有三个项目一个维护了五年的老服务pom 里锁死 JDK 8一个中台系统要求 JDK 11还有最近接的新项目CI 流水线直接用的 JDK 17 镜像。以前我图省事把三个版本的 JDK 压缩包全部解压到 /usr/local/java 下面目录名还起得特别像jdk8、jdk11、jdk17。每次切换项目我就去改 /etc/profile 里的 JAVA_HOME改完还要重新登录终端才放心。这套流程看着简单实际用起来全是坑改错一个字符、忘记 source、几个终端窗口状态不一致每一样都能浪费半小时。后来我在一次线上事故里彻底受够了。当时切完版本忘了验证直接跑部署脚本脚本里用的是 $JAVA_HOME/bin/java 启动结果 JAVA_HOME 指向的还是旧 JDK新代码里的 API 在老版本上不存在启动直接失败。那次之后我就下定决心一定要有个可靠的、可验证的版本切换工具。1.2 一个好用的切换器应该满足什么在动手写之前我先梳理了需求。我需要的不是那种能用就行的临时方案而是一个能长期稳定使用、切换结果可预期、出问题还能快速定位的工具。具体来说至少要满足四点第一能管理多个 JDK 版本并且知道每个版本安装在哪里。版本号和路径的对应关系要一目了然不能靠脑子记。第二切换命令要简单一条命令搞定不需要记一长串 export。第三切换后要立刻看到效果当前终端马上生效不需要重新登录或者重开窗口。第四切换结果要可查JAVA_HOME、PATH、java -version 三个信息能同时确认避免改了但没完全改的模糊状态。理清这四点之后我再去对比了几种常见方案发现没有一个是完全满足的这才决定自己写脚本。下一部分我把对比过程详细讲一下你就知道为什么现成方案总差那么点意思。2. 方案选型别急着写脚本先对比一下2.1 update-alternatives 的适用边界Linux 上最官方的多版本切换工具是 update-alternatives很多教程都会推荐。它的本质是维护一组符号链接比如 /usr/bin/java 默认指向 /etc/alternatives/java而 alternatives 又指向某一个具体的 JDK 路径。执行 sudo update-alternatives --config java 就能交互式选择要用的版本。这个方案系统级生效对新装机的环境来说确实方便不需要自己写任何东西。但用在真实项目里有两个明显的问题。第一个问题是它只管命令本身java、javac 这些可执行文件会被切换但 JAVA_HOME 环境变量并不会跟着变而 Maven、Gradle、Spring Boot 启动脚本这些工具恰恰只认 JAVA_HOME。你 update-alternatives 切得再欢mvn 编译用的还是老版本等于白切。第二个问题是它需要 sudo 权限而且切换是全局的想给不同终端窗口配不同版本就非常别扭一个终端切到 8另一个终端想要 17做不到。所以我的结论是update-alternatives 适合服务器上固定一个默认版本的场景比如生产环境的 OpenJDK 维护放到日常多版本开发的笔记本上就差了点意思。2.2 手动改环境变量的痛点另一条路是手动管理环境变量也就是在 ~/.bashrc 或 /etc/profile.d/ 下写好某个版本的 JAVA_HOME 和 PATH再 export 出去。这种方式最直观也最容易理解很多入门教程教的就是这套。但痛点很真实每切一次版本就要改一次文件改了之后当前终端不生效得 source 一下source 完如果 PATH 的拼接顺序不对旧的 java 路径残留然后整个环境就乱了。我遇到过最典型的情况是 PATH 里同时存在两个 JDK 的 bin 目录java 命令命中旧的那个而 JAVA_HOME 指向新的两边不一致。当时我反复确认 JAVA_HOME 是对的但 java -version 就是不变排查了半天才发现是 PATH 顺序的锅。因为 shell 解析 java 命令时是沿着 PATH 目录从左往右找的找到第一个就停止排在后面的等价命令根本没机会被命中。手动方案适合一年换一次版本的人对频繁切换的日常开发来说纯粹是给自己找麻烦。而且这种方式改的是全局配置文件多人共用一台开发机的时候还会影响到别人的环境。2.3 为什么我选择自研脚本后来我也试过 jenv 这类工具。jenv 的理念是对的通过 shim 机制把版本切换做得很优雅但装完还得跟 shell 钩子打交道还要维护 ~/.jenv/versions 底下的版本目录对大多数场景来说引入了一个不算轻的依赖。用了一段时间总觉得黑盒成分太多出了问题不好定位。最后我决定自己写一个几十行的 bash 脚本。用关联数组维护版本号到安装路径的映射切换时同时更新 JAVA_HOME 和 PATH并且主动清理 PATH 里属于旧 JDK bin 的残留项。脚本只做一件事切换逻辑透明确切出问题也知道去查哪一行。现在用了一年多稳定性和效率都没让我失望。就我的经验而言工具越小、越贴合自己的环境越好维护。完整代码和用法在下一部分你可以直接复制回去改路径就能用。2.4 动手前先把 JDK 装好并登记路径写脚本之前有个前置工作容易被忽略先把各个版本的 JDK 装好并且把路径固定下来。这里分享下我的习惯。Oracle JDK 和 OpenJDK 都行我一般从官网下载 tar.gz 压缩包解压到 /usr/local/java 目录下目录名带上完整版本号比如 jdk-17.0.10、jdk-11.0.22。这样做的好处是路径稳定、可预期脚本里登记的就是这些路径。如果你用的是 Ubuntu 或者 Debian也可以走 apt 安装装完的 JDK 都在 /usr/lib/jvm 下目录名类似 jdk-17-openjdk-amd64。这个没问题脚本里把对应路径登记进去就行。但我个人更推荐统一用 tar.gz 解压的方式因为 apt 仓库里的 OpenJDK 版本更新有滞后而且不同发行版的目录命名习惯不一样换台机器容易踩坑。装好之后我建议先手动验证一下跑一下 /usr/local/java/jdk-17.0.10/bin/java -version确认这个路径下的 java 能正常工作。这个验证非常重要因为脚本只管切换管不了 JDK 本身是否损坏。路径都没确认清楚就写进脚本到时候切过去才发现是个坏的 JDK排查起来更费劲。3. 核心实现写一个可靠的切换脚本3.1 脚本设计要点写这个脚本之前我先想清楚了几个关键点这里也分享给你。第一个是必须用 source 执行。bash 脚本如果直接运行它是在子进程里跑的脚本里 export 的环境变量在脚本结束后就没了当前终端根本不会变。所以切版本的本质是修改当前 shell 的环境必须 source 脚本。我在脚本开头加了一层判断如果检测到你是直接 bash 运行而不是 source就直接提示并退出避免误用。第二个是 PATH 的清理顺序。正确的做法是先把 PATH 里所有 JDK 的 bin 路径剔除掉再把新版本的 bin 追加到最前面而不是简单地 export PATH$JAVA_HOME/bin:$PATH。后者会让 PATH 越拼越长旧路径永远清理不干净最后 java 命中的可能是任意一个版本完全不可控。第三个是要把检查放在前面。版本不存在、路径不存在就直接报错退出别等 export 完了才发现路径是错的。脚本的容错要写在入口处而不是写到一半再回头处理。这三个点做到脚本的可用性就有保障了。3.2 完整脚本与用法说明我用的是下面这份 bash 脚本代码不长但每个函数都有明确职责。直接贴出来给你看#!/usr/bin/env bash # jdk-switch.sh - Linux JDK 版本切换器 # 登记的 JDK 安装路径请按自己的实际路径修改 declare -A JDK_MAP( [8]/usr/local/java/jdk1.8.0_202 [11]/usr/local/java/jdk-11.0.22 [17]/usr/local/java/jdk-17.0.10 [21]/usr/local/java/jdk-21.0.2 ) # 清理 PATH 中所有已登记的 JDK bin 路径 clean_old_jdk_path() { local cleaned local IFS: for p in $PATH; do local matched0 for v in ${!JDK_MAP[]}; do if [ $p ${JDK_MAP[$v]}/bin ]; then matched1 break fi done if [ $matched -eq 0 ]; then cleaned${cleaned:$cleaned:}$p fi done export PATH$cleaned } switch_jdk() { local version$1 local jdk_path${JDK_MAP[$version]} if [ -z $jdk_path ]; then echo 不支持 JDK $version可用版本: ${!JDK_MAP[]} 2 return 1 fi if [ ! -d $jdk_path ]; then echo JDK $version 路径不存在: $jdk_path 2 return 1 fi clean_old_jdk_path export JAVA_HOME$jdk_path export PATH$JAVA_HOME/bin:$PATH echo 已切换到 JDK $version echo JAVA_HOME$JAVA_HOME echo PATH 前缀${JAVA_HOME}/bin java -version } if [[ ${BASH_SOURCE[0]} ${0} ]]; then echo 请使用 source 加载: source ./jdk-switch.sh 17 2 exit 1 fi switch_jdk $1用的时候也很直接。先 source 脚本再传版本号参数source ./jdk-switch.sh 17看到输出里显示已切换到 JDK 17和 java 版本信息就说明切换成功了。想切回 8再 source 一次传 8 即可。脚本会自动清理 PATH 里的旧 JDK 路径不会留下脏数据。脚本对 bash 版本有要求关联数组是 bash 4.0 开始支持的特性Linux 发行版自带的 bash 基本都没问题如果用 macOS 系统自带的 bash 3.2 会报错换成新版 bash 或者改用其他脚本语言实现都行。你不需要理解脚本每一行但建议至少看明白 clean_old_jdk_path 这个函数在干什么。它做的事情是遍历当前 PATH 里的所有目录如果某个目录正好等于登记过的某个 JDK 的 bin 路径就剔除掉剩下的保留。这样无论你之前切到哪个版本PATH 里都不会残留旧 JDK 的影子。3.3 底层原理JAVA_HOME 和 PATH 是怎么影响 java 命令的很多人切换 JDK 只盯着 java -version 看其实没搞懂背后的机制。Linux 下执行 java 命令时shell 会在 PATH 环境变量列出的目录里挨个找名为 java 的可执行文件找到第一个就停止。所以 PATH 目录的先后顺序决定了你用的是哪个 java。如果 /usr/bin 排在前面而 /usr/bin/java 又是 update-alternatives 维护的软链那么无论你 export 什么 JAVA_HOMEjava 命令都可能命中系统默认版本。JAVA_HOME 则是给那些不自己去 PATH 里找 java的程序用的典型的就是 Maven、Gradle还有各种启动脚本里写 $JAVA_HOME/bin/java 的程序。它们不关心 PATH只认 JAVA_HOME 这个变量。理解了这层关系就明白为什么只改 JAVA_HOME 或者只改 PATH 都不行改了 JAVA_HOMEjava 命令的实际解析可能还是旧的只改了 PATHMaven 拿到的还是旧 JAVA_HOME。我的脚本把两个变量一并处理同时通过清理旧 bin 路径保证 java 命中的一定是刚切过去的那份。用一个生活化的类比来解释PATH 就像小区门口的指路牌写在最前面的路标会被第一个看到JAVA_HOME 则是快递单上的收货地址快递员只认这个地址不看路牌。两个信息必须同时正确包裹才能送到正确的人手里。4. 实操验证与常见问题排查4.1 切换后没生效先按顺序查这三件事脚本写完之后我在自己机器上跑了一段时间也帮同事排查过几次总结了三个最高频的切换没生效原因按排查顺序列给你。第一确认当前 shell 是否真的 source 了脚本。很多人直接 bash jdk-switch.sh 17 来跑结果在当前终端里 java -version 完全没变因为子进程里 export 的东西根本带不出来。这也是我在脚本里加了误用提示的原因看到请使用 source 加载这句话就说明你运行方式不对。第二执行 command -v java 看它指向哪里。如果结果是 /usr/bin/java那很可能是系统通过 update-alternatives 预设的软链在起作用。这时候要看 PATH 里 /usr/bin 是不是在 $JAVA_HOME/bin 前面。这种场景下你需要调整 PATH 顺序或者确认脚本已经把新 bin 放在最前面。第三如果 command -v java 已经指向 $JAVA_HOME/bin/java但 java -version 还是老的多半是当前 shell 缓存了命令路径。bash 会把最近查找过的命令路径存进哈希表再次执行时直接走缓存不重新搜 PATH。执行 hash -r 清理一下哈希缓存再试就行。这三步基本能解决九成的没生效问题。4.2 高频问题速查表我把实际使用中遇到的典型问题整理成了下面这个表每个都包含现象、原因和解决办法方便你遇到问题时直接对着查现象可能原因解决办法java -version 没变化直接 bash 执行脚本export 没生效改用 source 加载脚本command -v java 显示 /usr/bin/javaPATH 中 /usr/bin 排在 JDK bin 前面调整 PATH 顺序或确认脚本把 $JAVA_HOME/bin 放最前command -v java 正确但版本仍旧shell 命令路径哈希缓存执行 hash -r 清除缓存Maven 编译用的 JDK 不对Maven 读的是 JAVA_HOME不是 PATH切换后 echo $JAVA_HOME 确认重新 source 后再跑 mvn新开终端又变回默认版本切换只对当前 shell 生效把默认版本 export 写入 ~/.profile提示不支持的版本JDK_MAP 里没有登记该版本在脚本数组里补上对应版本号和路径切换后其它命令报 PATH 错误clean 函数误删了非 JDK 路径确认 clean 函数匹配规则只针对登记过的 JDK bin 目录source 时报语法错误bash 版本低于 4.0升级 bash或用兼容写法替代关联数组4.3 我把这些坑都踩了一遍这里再分享几个脚本之外的坑都是我真实踩过的。第一个坑是 Ubuntu 上 apt 安装的 openjdk 路径问题。apt 装出来的 JDK 都在 /usr/lib/jvm 下而且目录名带版本号比如 jdk-17-openjdk-amd64。这没问题。但如果你还装了 Oracle JDK 放在 /usr/local/java两个来源的路径风格完全不同脚本登记路径时一定要逐个确认目录真实存在。我建议在登记前先 ls 一眼别凭印象写路径否则切过去直接提示路径不存在还以为是脚本 bug。第二个坑是切换版本后马上跑 mvn -version有时候版本号没变其实不是脚本问题是 mvn 这个 shell wrapper 里可能缓存了旧的 JAVA_HOME或者你开了多个终端窗口当前窗口的环境变量还是老的。多窗口环境下每个窗口都得单独 source。我在实际工作中就吃过这个亏终端 A 切到 17 编好了包终端 B 没切直接打包结果 CI 里跑出来的产物对不上。第三个坑是 shell 配置文件的优先级。如果你把默认 JAVA_HOME 写在 /etc/profile 里又在 ~/.bashrc 里 source 切换脚本不同终端登录时加载顺序不一样可能造成行为不一致。我后来统一把默认版本写在 ~/.profile 里切换脚本只负责临时切换两者互不干扰。5. 进阶用法让切换器适配真实工作流5.1 按项目目录自动选 JDK脚本在手动切换场景下已经很顺手了但如果你跟我一样经常在多个项目间跳来跳去还可以再加一个更省心的功能进入项目目录时自动切换对应 JDK 版本。思路是在项目根目录放一个隐藏文件比如 .jdk-version里面写一行版本号17。然后在 ~/.bashrc 里加一个钩子每次 cd 到新目录时检查当前目录有没有这个文件有就读取内容自动调用脚本切换。我用的是 PROMPT_COMMAND 的方式在每次提示符出现前执行一个检查函数函数逻辑很轻量auto_switch_jdk() { if [ -f .jdk-version ]; then local target_version$(cat .jdk-version | tr -d \n) local current_version$(echo $JAVA_HOME | grep -o [0-9]\ | head -1) if [ -n $target_version ] [ $target_version ! $current_version ]; then source ~/tools/jdk-switch.sh $target_version fi fi } PROMPT_COMMANDauto_switch_jdk这个功能加上之后基本就告别手动切版本了。进入老项目目录终端自动切到 8切到新项目目录自动切到 17。这里判断当前版本的方式比较粗略只抓了 JAVA_HOME 里第一个数字对于 jdk-17.0.10 这种路径能正常工作。如果你的路径命名方式不一样建议用更严谨的匹配方式或者直接比较完整路径。有一点要提醒PROMPT_COMMAND 里的函数会在每次提示符渲染前执行所以逻辑一定要轻量别在里面做重活否则终端会明显变卡。判断尽量用文件存在性和短字节读取不要每次都去解析大文件。5.2 与构建工具和 IDE 的配合切换脚本管的是终端环境但真实开发里还有两个环节容易忽略构建工具和 IDE。构建工具这边Maven 和 Gradle 都通过 JAVA_HOME 找 JDK所以在跑 mvn clean package 之前先确认当前 shell 的 JAVA_HOME 是不是你要的那个版本最直接的方式是看 mvn -version 输出里的 Java version 那行。另外 Gradle 还有自己的 daemon 进程daemon 启动时会锁定一个 JDK 版本如果你切换了 JDK最好执行 gradle --stop 把旧 daemon 停掉再重新构建否则它可能一直用旧版本跑。IDE 这边IDEA 的 Project Structure 里有独立的 Project SDK 设置IDE 配置和终端环境是两套体系终端切到 JDK 8 不代表 IDEA 里也切了反之亦然。我个人的做法是终端环境用脚本管IDEA 里每个项目单独指定 Project SDK两者各司其职。如果你用 IDEA 的 Terminal 面板它继承的是 IDE 启动时的环境变量脚本切换在 IDEA 里不一定生效所以别在 IDEA 内嵌终端里指望脚本能改变整个 IDE 的编译环境。5.3 日常使用的几个习惯脚本本身不算复杂但真正让一套工具长期好用的是使用习惯。我在实际使用中总结了一个习惯清单切完版本先跑一下 echo $JAVA_HOME java -version 确认两个信息一致跑构建工具前先 mvn -version 或 gradle -v 看一眼实际生效版本新开终端如果默认版本不对先检查 ~/.profile 和 ~/.bashrc 里有没有重复 export遇到诡异问题先 hash -r 再试。这些习惯花不了几秒钟但能省掉很多后面排查的时间。另外一点脚本不要写死在某个角落里建议放到 ~/bin 或者你自己的工具目录里并且建一个软链方便调用。我现在是直接 source ~/tools/jdk-switch.sh 17简单稳定不容易忘。这个切换器我用了快两年没有出过一次切换错误每次都能准确命中预期的 JDK 版本。如果你的场景跟我类似多个版本常年共存、项目间切换频繁这套方案可以直接拿去用把路径改成你自己的就行。