1. 项目缘起一个Java开发者桌面上的“多版本”刚需如果你是一个在Ubuntu上搞Java开发的不管是做后端服务、大数据处理还是Android应用大概率会遇到一个绕不开的麻烦不同项目依赖的JDK版本不一样。老项目可能还死守着JDK 8新项目已经用上了JDK 17的ZGC而你想尝鲜体验一下JDK 21的虚拟线程又不想把环境搞得一团糟。直接在Ubuntu上用apt install openjdk-11-jdk装一个版本很简单但当你需要同时管理多个版本并且能像开关灯一样快速切换时事情就变得复杂了。手动改JAVA_HOME、手动调整PATH不仅容易出错而且每次切换都像在走钢丝一不小心就把其他工具链搞崩了。所以一个清晰、稳定、可脚本化的多版本JDK管理方案就成了生产力工具链中不可或缺的一环。今天要聊的就是在Ubuntu 22.04 LTS这个相当流行的开发平台上如何干净利落地安装JDK 8、11、17、21这四个主流及过渡版本并搭建一个可以随心所欲、一键切换的机制。我会把每一步的原理、踩过的坑和最佳实践都摊开来讲清楚目标是让你看完之后能建立起一个“金刚不坏”的本地Java开发环境。2. 策略选择为什么不用apt而用手动下载环境变量管理在开始动手前我们先要统一思想方法决定效率。对于多版本JDK管理常见的有几种路子使用Ubuntu官方APT仓库安装sudo apt install openjdk-11-jdk。这是最省事的单版本安装方式。但对于多版本管理它的弊端很明显不同版本包的安装路径不统一有的在/usr/lib/jvm/下有的可能在其他地方版本更新受制于Ubuntu仓库的更新节奏比如你想装最新的JDK 21.0.3但仓库里可能只有21.0.1。最关键的是APT不提供官方的、便捷的版本切换命令。使用SDKMAN!这是一个非常优秀的工具专门用于管理多个SDK版本包括Java、Maven、Gradle等。对于新手或者追求极致便捷的用户我其实会首推SDKMAN!。但今天我们要探讨的是更底层、更可控的手动方案。理解手动方案能让你对JAVA_HOME、PATH这些核心环境变量有更深刻的认识以后无论遇到什么环境问题都能自己解决。而且在一些对网络或安装工具有严格限制的环境比如某些内网开发机手动部署是唯一的选择。手动下载.tar.gz包手动配置环境变量这就是我们今天要采用的“硬核”方法。它的优势在于完全可控版本任选可以精确到某个构建号安装目录自定切换逻辑透明。缺点就是需要自己多敲一些命令但一旦设置好就是一劳永逸的。我们的核心思路是独立安装将每个JDK版本解压到独立的目录例如/usr/lib/jvm/jdk-11.0.22/。彼此隔离互不影响。符号链接指向当前版本创建一个通用的符号链接例如/usr/lib/jvm/current-jdk指向我们当前想使用的那个JDK目录。环境变量引用符号链接将JAVA_HOME环境变量设置为这个符号链接并将$JAVA_HOME/bin加入PATH的最前面。切换版本只需更改符号链接的指向然后重新加载环境变量或新开终端就完成了切换。这个方法清晰、可靠并且与很多自动化脚本和IDE的JDK探测逻辑兼容。3. 实战部署一步步构建多版本JDK仓库接下来我们进入实操环节。请打开你的Ubuntu 22.04终端我们一步步来。3.1 准备工作清理旧版本与创建专属目录在安装新版本之前最好先检查一下系统里有没有通过APT安装的旧OpenJDK避免未来产生混淆。# 检查已安装的Java相关包 dpkg -l | grep -i openjdk # 如果你想移除它们请谨慎确保没有其他依赖 # sudo apt purge openjdk-* # 这会移除所有openjdk包可能过于激进 # 更推荐使用 apt remove 具体包名然后为我们的JDK们建立一个“家”。我习惯使用/usr/lib/jvm目录这是Linux下存放Java虚拟机的传统位置很多工具也会默认在这里寻找JDK。# 创建jvm目录如果不存在 sudo mkdir -p /usr/lib/jvm # 将目录所有权改为当前用户方便后续操作无需每次都sudo sudo chown -R $USER:$USER /usr/lib/jvm3.2 下载与安装四个目标JDK版本我们将从Oracle官网或更推荐的AdoptiumEclipse Temurin下载LTS版本的JDK。Adoptium提供高性能、跨平台、开源许可的JDK发行版是社区首选。1. 下载JDK压缩包你可以通过浏览器下载但我更推荐在终端里用wget这样容易记录和复现。# 进入我们准备好的目录 cd /usr/lib/jvm # 下载 JDK 8 (选择最新的8u版本例如8u402) wget https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u402-b06/OpenJDK8U-jdk_x64_linux_hotspot_8u402b06.tar.gz # 下载 JDK 11 (例如11.0.22) wget https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.22%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz # 下载 JDK 17 (例如17.0.10) wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.10%2B7/OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz # 下载 JDK 21 (例如21.0.2) wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2%2B13/OpenJDK21U-jdk_x64_linux_hotspot_21.0.2_13.tar.gz注意上面的URL可能会随着新版本发布而失效。最稳妥的方法是访问 Adoptium官网 或其 GitHub Releases页面 找到对应版本的Linux x64.tar.gz包右键复制链接地址。URL中的版本号如8u402b06请以你下载时的最新版本为准。2. 解压并重命名目录解压后为了目录名清晰易懂我们给每个版本一个简单的名字。# 解压JDK 8 tar -xzf OpenJDK8U-jdk_x64_linux_hotspot_8u402b06.tar.gz mv jdk8u402-b06 jdk-8 # 重命名为简洁的 jdk-8 # 解压JDK 11 tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz mv jdk-11.0.227 jdk-11 # 解压JDK 17 tar -xzf OpenJDK17U-jdk_x64_linux_hotspot_17.0.10_7.tar.gz mv jdk-17.0.107 jdk-17 # 解压JDK 21 tar -xzf OpenJDK21U-jdk_x64_linux_hotspot_21.0.2_13.tar.gz mv jdk-21.0.213 jdk-21 # 可选删除下载的压缩包以节省空间 rm *.tar.gz现在你的/usr/lib/jvm目录下应该有四个文件夹jdk-8,jdk-11,jdk-17,jdk-21。每个都是一个完整、独立的JDK。3.3 建立版本切换的指挥中心符号链接与环境变量这是实现便捷切换的核心。我们将创建一个名为current-jdk的符号链接并让系统环境指向它。1. 创建符号链接并设置默认版本假设我们想默认使用JDK 11。# 创建指向JDK 11的符号链接 ln -sfn /usr/lib/jvm/jdk-11 /usr/lib/jvm/current-jdk-s创建软链接-f强制覆盖已存在的链接-n防止链接指向目录链接时出现递归问题。现在/usr/lib/jvm/current-jdk就等价于/usr/lib/jvm/jdk-11。2. 配置全局环境变量我们需要修改shell的配置文件通常是~/.bashrc如果你使用Bash或~/.zshrc如果你使用Zsh。这里以Bash为例。# 打开配置文件 nano ~/.bashrc在文件的末尾添加以下内容# JDK 多版本管理配置 export JAVA_HOME/usr/lib/jvm/current-jdk export PATH$JAVA_HOME/bin:$PATH第一行将JAVA_HOME设置为我们的符号链接。第二行将$JAVA_HOME/bin添加到PATH环境变量的最前面。这样当你在终端输入java或javac时系统会优先使用我们符号链接指向的JDK版本。保存文件在nano中按CtrlX然后按Y再按Enter然后让配置立即生效source ~/.bashrc3. 验证安装现在检查一下是否配置成功java -version javac -version echo $JAVA_HOME你应该能看到JDK 11的版本信息并且JAVA_HOME输出为/usr/lib/jvm/current-jdk它指向jdk-11。4. 实现一键切换脚本化与手动两种方式环境搭好了怎么切换呢有两种主流方法手动改链接和编写切换脚本。4.1 手动切换理解原理手动切换是最直接的方式有助于理解背后的机制。比如现在要从JDK 11切换到JDK 17# 1. 更改符号链接指向 sudo ln -sfn /usr/lib/jvm/jdk-17 /usr/lib/jvm/current-jdk # 2. 重新加载环境变量使更改在当前shell生效 source ~/.bashrc # 3. 验证 java -version你应该会看到输出变成了JDK 17的信息。这个过程就是改变current-jdk这个“指针”的方向然后刷新一下系统对JAVA_HOME和PATH的认识。4.2 脚本化切换提升效率每次都敲命令记路径太麻烦。我们可以在家目录下创建一个Shell函数实现一键切换。编辑~/.bashrc文件在刚才添加的JAVA_HOME配置之后加入以下函数# JDK 版本切换函数 function switch-jdk() { local version$1 local jdk_path/usr/lib/jvm/jdk-$version if [ ! -d $jdk_path ]; then echo 错误未找到JDK版本 $version。 echo 可用的版本有 ls -d /usr/lib/jvm/jdk-* | xargs -I {} basename {} | sed s/jdk-// return 1 fi # 需要sudo权限修改/usr/lib/jvm下的链接 if sudo ln -sfn $jdk_path /usr/lib/jvm/current-jdk; then echo 已切换符号链接指向: $jdk_path # 重新导出JAVA_HOME和PATH给当前shell export JAVA_HOME/usr/lib/jvm/current-jdk export PATH$JAVA_HOME/bin:$(echo $PATH | sed -e s|$JAVA_HOME/bin:||) echo 当前JDK版本: java -version 21 | head -3 else echo 切换失败请检查权限。 return 1 fi }保存并source ~/.bashrc。现在你就可以在终端里使用这个酷炫的命令了# 切换到 JDK 8 switch-jdk 8 # 切换到 JDK 21 switch-jdk 21 # 如果不带参数或者参数不对会列出所有已安装版本 switch-jdk这个脚本做了几件事检查目标JDK是否存在更新符号链接并立即更新当前Shell会话的环境变量。注意里面更新PATH的那行sed命令它确保了PATH变量中旧的JDK bin路径被移除新的被加到最前避免了多个JDK路径在PATH中堆积造成混乱。5. 进阶整合让IDE和系统工具认准你的配置光在终端里能切换还不够我们的IDE如IntelliJ IDEA、VSCode和系统其他工具如Maven、Gradle也需要知道该用哪个JDK。5.1 配置IntelliJ IDEAIDEA非常智能它会自动扫描/usr/lib/jvm这样的标准目录。你可以在File - Project Structure - SDKs里点击“”号选择“Add JDK”然后导航到/usr/lib/jvm/jdk-11这样的具体目录IDEA会自动识别并添加。你可以把四个JDK都加进去然后在不同的项目里选择不同的SDK。更妙的是你可以直接添加/usr/lib/jvm/current-jdk这个符号链接作为SDK。这样当你在终端用switch-jdk命令切换后理论上IDEA里这个SDK的版本也会变可能需要重启IDEA或重新打开项目。但我个人更倾向于在IDEA里为每个项目固定一个具体的JDK路径避免因全局切换导致项目编译意外出错。5.2 配置系统级替代方案update-alternativesLinux系统提供了一个更底层的工具update-alternatives来管理系统命令的多个替代版本。我们可以用它来管理java和javac等命令。# 为每个JDK版本配置alternatives以jdk-11为例需要sudo sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-11/bin/java 1100 sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk-11/bin/javac 1100 # 同样地为jdk-8, jdk-17, jdk-21执行上述操作记得修改路径和优先级数字如800 1700 2100配置完成后你可以通过以下命令交互式地选择系统默认的Java版本sudo update-alternatives --config java它会列出所有已注册的Java可执行文件让你输入编号选择。这个方法设置的默认版本是系统全局的会影响所有用户和那些直接调用/usr/bin/java的脚本。那么它和我们基于JAVA_HOME的方案冲突吗实际上如果你在.bashrc中设置了PATH$JAVA_HOME/bin:$PATH由于$JAVA_HOME/bin在PATH中位于/usr/bin之前终端命令会优先使用我们符号链接指向的版本。update-alternatives更适合管理那些没有通过JAVA_HOME/bin覆盖到的系统默认命令。两种机制可以共存但理解其优先级PATH顺序优先很重要。6. 避坑指南与经验之谈搞定了主要步骤下面分享一些我趟过的雷和总结的经验能帮你节省大量排查时间。1. 权限问题我们一开始用sudo chown把/usr/lib/jvm目录所有权改给了当前用户这样在解压、创建链接时通常不需要sudo。但如果你在其他地方操作或者/usr/lib/jvm目录权限还原了就可能遇到权限错误。switch-jdk脚本里使用了sudo来修改current-jdk这个全局符号链接这是必要的。确保你的用户有sudo权限并且在执行时会提示输入密码。2. 环境变量不生效这是最常见的问题。修改.bashrc后必须执行source ~/.bashrc才能在当前终端生效或者干脆关闭终端重新打开一个新终端。如果你是在图形界面点击图标打开的IDE它启动时加载的是用户登录时的环境变量可能不会读取你刚刚修改的.bashrc。这种情况下你需要注销用户重新登录或者重启IDE有时IDE有“重启并重新加载环境”的选项。3. 符号链接的陷阱使用ln -sfn时务必确保目标路径是目录的真实路径而不是另一个符号链接。虽然我们的-n参数一定程度上能处理但最清晰的做法是直接指向解压后的那个实际目录如jdk-11。current-jdk本身作为一个符号链接指向一个实际目录这种单层间接关系是最安全可靠的。4. 版本验证切换版本后除了用java -version更严谨的验证方法是写一个简单的Java程序编译运行看看是否使用了正确的版本特性。例如用JDK 8编译一个带有Lambda表达式的程序然后在JDK 8下运行正常在只安装了JRE 8的环境下可能就跑不起来虽然我们的JDK包含JRE。这能综合检验javac和java命令是否来自同一套JDK。5. 关于JDK 8的特别说明JDK 8是一个比较老的版本在某些最新的Linux发行版上可能会因为依赖库版本太新而遇到一些兼容性问题比如与某些加密库相关。在Ubuntu 22.04上直接使用Adoptium的构建包通常没有问题。但如果遇到奇怪的问题可以尝试搜索“OpenJDK 8 Ubuntu 22.04”加上具体的错误信息社区通常有解决方案。6. 清理旧版本如果你后续想删除某个不用的JDK版本直接删除对应的目录即可例如rm -rf /usr/lib/jvm/jdk-8。然后记得从update-alternatives中移除它如果配置了的话sudo update-alternatives --remove java /usr/lib/jvm/jdk-8/bin/java。最后检查你的switch-jdk函数列表和IDE中的SDK配置做相应清理。7. 扩展思考这套方案的边界与优化现在你的多版本JDK管理堡垒已经建成了。但我们可以想得更远一点这个方案还有什么可以优化和注意的地方1. 用户级 vs 系统级我们的方案主要是在用户级别~/.bashrc进行配置。这意味着只有配置了这个环境的用户才能享受便捷切换。如果这台机器有多个开发用户并且都需要同样的多版本管理你有两个选择一是将JDK安装到/opt这样的公共目录并设置合适的读取权限然后指导每个用户在自己的.bashrc中设置JAVA_HOME指向/opt/jvm/current-jdk这个链接需要由管理员维护二是直接使用update-alternatives配置系统级的Java命令切换但这会影响所有用户。2. 与容器化开发的关系如今Docker等容器技术普及很多项目的开发环境直接定义在Dockerfile里本地只需要一个JDK来运行IDE和构建工具。此时本地多版本JDK管理的价值更多体现在构建工具链如Maven、Gradle和IDE本身的运行上。你的Maven可以配置不同的toolchains来为不同项目使用不同的JDK进行构建而这依赖于本地安装了多个JDK。所以本地多版本环境与容器化开发是互补的。3. 自动化安装脚本如果你需要频繁在新机器或虚拟机上搭建环境可以把上面的步骤写成一个完整的Shell脚本。脚本可以自动检测系统、下载指定版本的JDK、解压、配置环境变量、甚至安装update-alternatives。这能极大提升环境准备效率。脚本的核心逻辑就是本文所讲的内容。4. 为什么不用Docker来管理有人可能会问既然都用容器了为什么不在本地用Docker跑不同版本的JDK对于运行应用本身这当然是个好主意。但对于开发阶段你需要编译、调试、运行测试频繁地与IDE交互。虽然有些高级的远程开发模式但让IDE直接调用本地安装的JDK进行编译和运行在延迟和便利性上目前还是最优解。本地JDK提供了最“原生”的开发体验。回过头看手动管理多版本JDK看似有点“复古”但它给予开发者的那种完全掌控感和对底层机制环境变量、路径、符号链接的深刻理解是任何高级工具都无法替代的。当你下次遇到“ClassNotFound”或者“Unsupported major.minor version”这类错误时你就能非常自信地检查JAVA_HOME和PATH而不是一脸茫然。这种能力就是一个资深开发者工具箱里最坚实的底牌之一。