更新Java版本有两种主要方法：一是通过系统包管理器（如apt或dnf）安装并用update-alternatives切换，省心且适合生产环境；二是手动下载JDK压缩包解压后配置JAVA_HOME和PATH，并用update-alternatives注册，适用于需要最新或特定版本的场景。包管理器版本滞后是因发行版追求稳定与兼容性，测试周期长。手动安装需设置环境变量确保应用识别，推荐在/etc/profile.d/下创建脚本统一管理。多版本共存时，可用sudo update-alternatives --config java进行全局切换，或通过别名与JAVA_HOME实现项目级灵活控制，兼顾系统默认与局部覆盖需求。
在Linux系统上快速更新Java版本，这事儿说起来简单，但背后其实藏着一些小技巧和选择，尤其当你追求效率和稳定性时。核心思路无非两种：一是依赖系统自带的包管理器，简单省心；二是手动下载安装，虽然麻烦点，但能获得最新或特定版本。选择哪种，往往取决于你对版本新旧、系统洁净度和项目需求的权衡。
解决方案
更新Java版本，我通常会根据具体情况来决定。
方法一：通过系统包管理器
这是最省事的方法，尤其适用于生产环境或者你不需要最新、最前沿的Java版本时。
立即学习“Java免费学习笔记（深入）”；
对于基于Debian/Ubuntu的系统（使用apt
）：
-
检查可用版本：
apt search openjdk | grep jdk
这会列出仓库中所有可用的OpenJDK版本，比如
openjdk-11-jdk
、openjdk-17-jdk
等。 -
安装特定版本： 假设你想安装OpenJDK 17：
sudo apt update sudo apt install openjdk-17-jdk
如果系统提示已安装最新版本，或者你想升级已有的版本，
apt upgrade
通常会处理。但如果想从JDK 11升级到JDK 17，直接安装JDK 17然后用update-alternatives
切换是更清晰的做法。 -
设置默认Java版本： 安装完成后，系统通常会自动注册新版本。但为了确保，或者在多个版本间切换，我们需要使用
update-alternatives
：sudo update-alternatives --config java
这个命令会列出所有已安装的Java运行时，并让你选择一个作为系统默认。你需要输入对应数字来选择。
别忘了也为
javac
和jar
等工具设置：sudo update-alternatives --config javac sudo update-alternatives --config jar
对于基于RHEL/CentOS/Fedora的系统（使用yum
或dnf
）：
-
检查可用版本：
dnf search openjdk
或
yum search openjdk
这会显示可用的OpenJDK包，例如
java-17-openjdk
。 -
安装特定版本：
sudo dnf install java-17-openjdk-devel
或
sudo yum install java-17-openjdk-devel
devel
包通常包含了JDK（开发工具包），而不仅仅是JRE（运行时环境）。 -
设置默认Java版本： RHEL系的系统也有类似的
alternatives
工具：sudo alternatives --config java
同样，选择你想要的版本。
方法二：手动下载并安装
当你需要某个包管理器里没有的最新版本，或者特定厂商（如Oracle）的JDK时，手动安装是必经之路。
下载JDK包： 前往Oracle官网（需要注册）或OpenJDK官网下载你需要的
.tar.gz
压缩包。例如，下载jdk-17.0.8_linux-x64_bin.tar.gz
。-
解压到指定目录： 我习惯将其解压到
/opt/java
或/usr/local/java
，这样方便管理。sudo mkdir -p /usr/local/java sudo tar -xzf jdk-17.0.8_linux-x64_bin.tar.gz -C /usr/local/java
解压后，你会在
/usr/local/java
下看到一个类似jdk-17.0.8
的目录。 -
配置环境变量： 这步是关键。你需要告诉系统Java在哪。编辑
~/.bashrc
（仅对当前用户）或/etc/profile
（对所有用户）或在/etc/profile.d/
下创建新文件（推荐）。创建一个新文件，例如
/etc/profile.d/jdk17.sh
：
CuuMall免费开源网上商城系统下载强大、易用的CuuMall发布新版本了，CuuMall网上商城系统是使用PHP开发的一套免费的开源商城系统，CuuMall最新版本v2.3在CuuMall v2.2稳定版本的基础上做了三十多项大小功能的升级及改进，此次更新进一步完善了CuuMall商城系统，使得2.3版本的CuuMall免费商城系统更加稳定，速度更快，上手更容易！ CuuMall商城秉承简单易用的理念，将购物流程、开店流程尽量的简
sudo nano /etc/profile.d/jdk17.sh
添加以下内容（请根据你的实际路径和版本号修改）：
export JAVA_HOME=/usr/local/java/jdk-17.0.8 export PATH=$JAVA_HOME/bin:$PATH
保存并退出。然后让配置生效：
source /etc/profile.d/jdk17.sh # 或者直接重启终端
-
使用
update-alternatives
注册手动安装的JDK： 这一步是让系统全局识别你的手动安装版本，并能与其他版本切换。sudo update-alternatives --install "/usr/bin/java" "java" "/usr/local/java/jdk-17.0.8/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/local/java/jdk-17.0.8/bin/javac" 1 sudo update-alternatives --install "/usr/bin/jar" "jar" "/usr/local/java/jdk-17.0.8/bin/jar" 1 # ...以此类推，注册你需要的其他Java工具
这里的
1
是优先级，数字越大优先级越高。 注册完成后，就可以用sudo update-alternatives --config java
来切换了。
为什么有时候包管理器里的Java版本不是最新的？
这是一个很常见的问题，尤其对于那些追求最新技术栈的开发者来说。我个人就经常遇到这种情况，明明Oracle官网都发布了JDK 21，我系统里的包管理器却还在提供JDK 17或者更老的版本。这背后有几个原因：
首先，稳定性优先。Linux发行版，尤其是企业级发行版（比如CentOS、RHEL），它们的核心理念是稳定压倒一切。一个Java新版本从发布到被纳入发行版的官方仓库，需要经过漫长的测试和验证过程，以确保它与系统中的其他组件、库都能和谐共存，不会引入新的bug或安全漏洞。这个过程可能需要几个月甚至更长时间。对于服务器环境来说，这种保守策略是明智的，没人希望因为一个Java版本更新导致整个服务崩溃。
其次，维护成本和兼容性。维护一个软件包仓库需要大量的人力物力。每个新版本的软件都需要专业的打包人员进行适配、测试和维护。如果发行版频繁地将所有软件都更新到最新版本，那么维护成本会急剧增加，而且也更容易出现不同软件版本之间的兼容性问题。
再者，上游发布周期。OpenJDK本身有自己的发布周期，而各大Linux发行版也有自己的大版本发布周期。通常，发行版会选择在某个时间点“冻结”其软件版本，之后只进行安全更新和bug修复，而不会引入新的主要版本。所以，如果你使用的发行版版本比较旧，那么即使OpenJDK发布了新版本，你可能也无法通过包管理器获得。
所以，当我在一个新项目需要某个最新Java特性时，如果包管理器没有，我通常不会等，直接手动安装是更高效的选择。虽然失去了包管理器自动更新的便利，但换来了版本自由。
手动安装Java后，如何确保系统正确识别并使用它？
手动安装Java后，最关键的一步就是让系统知道它的存在，并且能正确地调用它。这主要涉及到两个核心点：环境变量的设置和
update-alternatives工具的使用。
首先是环境变量。
JAVA_HOME这个变量是Java生态系统中一个约定俗成的标准，很多Java应用程序（比如Maven、Tomcat、Spring Boot应用）会依赖它来找到Java的安装路径。如果你只是把Java解压了，但没有设置
JAVA_HOME，那么这些应用就可能找不到JDK。我通常会在
/etc/profile.d/目录下创建一个脚本文件（比如
jdk.sh），把
export JAVA_HOME=/path/to/your/jdk和
export PATH=$JAVA_HOME/bin:$PATH这两行加进去。这样，每次系统启动或者新开一个shell，这些变量都会被加载。
PATH变量的作用是让你的shell在任何目录下都能直接执行
java、
javac等命令，而不需要输入完整的路径。
其次是update-alternatives
。这个工具是Linux系统用来管理同一功能多个实现的一种机制。比如，系统里可能有多个Java版本，多个Python版本，或者多个文本编辑器。
update-alternatives通过创建符号链接的方式，让
/usr/bin/java这样的通用路径指向你选择的特定Java版本。手动安装的JDK，如果你不通过
update-alternatives --install把它注册进去，系统默认是不知道它的。它就像一个“注册中心”，你把新安装的JDK“登记”进去，然后才能用
update-alternatives --config java来在不同版本间进行切换。我曾经就犯过只设置
JAVA_HOME但忘了注册
javac的错误，结果编译代码的时候总是报错说找不到
javac，排查了好久才发现是这个原因。所以，注册时记得把
java、
javac、
jar这些常用工具都注册上。
这两个机制各有侧重，但都不可或缺。
JAVA_HOME更多是给Java应用和构建工具看的，而
PATH和
update-alternatives则是给操作系统和命令行用户看的。两者配合，才能确保你的手动安装版本被系统全面、正确地识别和使用。
在多版本Java并存的环境中，如何灵活切换？
在开发环境中，我们经常会遇到需要同时维护多个Java项目的场景，而这些项目可能依赖于不同的Java版本。比如，一个老项目还在用JDK 8，而新项目已经用上了JDK 17。这时，灵活切换Java版本就变得至关重要。我个人觉得，
update-alternatives工具在这里扮演了核心角色，但结合环境变量的使用，可以实现更细粒度的控制。
利用update-alternatives
进行系统级切换：
这是最直接、最常用的方式。当你需要全局切换Java版本时，比如从JDK 11切换到JDK 17，只需执行：
sudo update-alternatives --config java
系统会列出所有已注册的Java版本，并提示你选择一个数字来设定默认。这个操作会修改
/etc/alternatives/java（以及其他相关工具如
javac）指向的实际JDK路径，从而影响到所有通过
java命令启动的程序。它的优点是简单、全局生效，缺点是如果你有多个终端会话，可能需要重新登录或
source一下你的shell配置文件才能完全生效。
结合JAVA_HOME
进行应用级或项目级切换：
虽然
update-alternatives很方便，但它修改的是系统的默认
java命令。有些Java应用或构建工具（例如Maven、Gradle、Tomcat、IntelliJ IDEA等）并不完全依赖系统的
PATH变量或
update-alternatives的设置，它们更倾向于直接读取
JAVA_HOME环境变量来确定使用哪个JDK。
这意味着，即使你用
update-alternatives把系统默认设为JDK 17，但如果你在一个项目目录里，通过脚本设置了
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64，那么这个项目就会使用JDK 8。这种方式提供了极大的灵活性，允许你在不同的项目目录中，通过不同的shell脚本或IDE配置来指定各自的JDK版本，而无需频繁地修改系统全局设置。
我经常在项目的
.env文件或者构建脚本（比如
pom.xml或
build.gradle）中明确指定
JAVA_HOME，确保项目在任何环境下都能使用正确的JDK版本。例如，在
.bashrc或
.zshrc中，我可以定义一些别名或函数来快速切换
JAVA_HOME：
# 在 ~/.bashrc 或 ~/.zshrc 中 export JAVA_8_HOME="/usr/lib/jvm/java-8-openjdk-amd64" export JAVA_17_HOME="/usr/local/java/jdk-17.0.8" alias usejdk8="export JAVA_HOME=$JAVA_8_HOME && export PATH=$JAVA_HOME/bin:$PATH && java -version" alias usejdk17="export JAVA_HOME=$JAVA_17_HOME && export PATH=$JAVA_HOME/bin:$PATH && java -version"
这样，我只需要在终端输入
usejdk8或
usejdk17，就可以快速切换当前会话的
JAVA_HOME和
PATH，从而改变当前终端中Java命令的行为。这种方式对于开发人员来说，简直是多版本管理的神器，省去了很多麻烦。
总的来说，
update-alternatives负责系统全局的“默认”选择，而
JAVA_HOME则提供了更细粒度的“覆盖”能力，让你可以在特定场景下使用非默认的Java版本。两者结合，就能在多版本Java并存的环境中游刃有余。
