使用update-alternatives或设置JAVA_HOME可切换Linux中Java版本，前者系统级管理推荐全局使用，后者灵活适用于特定会话；还可通过SDKMAN!或asdf-vm等工具简化多版本管理。
在Linux系统里切换Java版本，通常我会倾向于使用系统自带的 update-alternatives 命令来管理，或者直接修改环境变量 JAVA_HOME。这两种方法各有侧重，前者更系统化，后者更灵活，尤其适合在特定项目或终端会话中快速调整。
解决方案
要切换Linux系统中的Java版本，我通常会采用两种核心策略，具体选择哪种取决于我的需求和系统配置。
方法一：使用 update-alternatives (推荐)
这是Debian/Ubuntu系发行版（以及一些RHEL/CentOS系通过类似机制）管理系统级默认程序版本的一种标准方式。它为系统中安装的多个同类程序（比如不同的Java版本）提供了一个统一的切换接口。
立即学习“Java免费学习笔记（深入）”；
-
列出所有已注册的Java版本： 通常，当你通过包管理器安装Java时，它们会自动注册到
update-alternatives。你可以先看看系统里都有哪些“候选者”：sudo update-alternatives --config java
这个命令会列出所有可用的Java运行时，并让你选择一个作为默认。它会显示一个数字列表，每个数字对应一个Java版本及其安装路径。
-
选择你想要的Java版本： 根据提示，输入对应数字即可。比如，如果你想切换到
java-11-openjdk，就输入它前面的数字。There are 2 choices for the alternative java (providing /usr/bin/java). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib/jvm/java-17-openjdk-amd64/bin/java 1711 auto mode 1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode 2 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 manual mode Press <enter> to keep the current choice[*], or type selection number: 1
这样，系统默认的
java命令就会指向你选择的版本。对于javac、javadoc等工具，也需要类似地配置：sudo update-alternatives --config javac sudo update-alternatives --config jar # ...以此类推，根据你需要管理的Java工具进行配置
这方法的好处是全局生效，对所有新开启的终端会话都有效，并且管理起来比较清晰。
方法二：通过设置环境变量 JAVA_HOME
这种方式更“原始”一些，但非常灵活，尤其适合在不影响系统全局配置的情况下，为特定用户、特定项目或特定终端会话临时切换Java版本。
找到你的Java安装路径： 你需要知道你想要使用的Java版本的根目录。例如，OpenJDK 11 可能在
/usr/lib/jvm/java-11-openjdk-amd64，Oracle JDK 8 可能在/opt/jdk1.8.0_202。-
设置
JAVA_HOME环境变量： 在你的 shell 配置文件（比如~/.bashrc、~/.zshrc或~/.profile）中添加或修改JAVA_HOME和PATH变量。 例如，要切换到 Java 11：export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH
保存文件后，需要重新加载配置文件才能生效：
source ~/.bashrc # 或你修改的那个文件
如果你只是想在当前终端会话中临时切换，直接在命令行执行
export命令即可，关闭终端后就会失效。 这种方法让我可以快速在不同项目之间切换JDK，比如一个老项目需要Java 8，新项目需要Java 17，我只需要修改一下当前会话的环境变量就行，互不干扰。
为什么需要管理多个Java版本？
这其实是个很常见的场景，尤其对于开发者来说。我个人就经常遇到这样的情况：手头可能同时有几个项目在进行，而这些项目由于历史原因、技术栈选择或者客户要求，各自依赖着不同的Java版本。比如，一个遗留系统可能还跑在Java 8上，因为升级成本太高或者依赖的库不支持新版本；而新开发的微服务项目则会尽可能地使用最新的LTS版本，比如Java 17，以享受性能提升和新特性。
此外，有时候我还会在学习或测试新版Java特性时，需要安装一个尝鲜版，但又不想影响我日常工作的主力JDK。这种多版本共存的需求，使得有效的Java版本管理成为一个必不可少的技能。它能确保我的开发环境能够灵活适应各种项目需求，避免版本冲突带来的各种“奇奇怪怪”的问题，提高开发效率。
如何验证当前Java版本是否切换成功？
验证Java版本是否切换成功，其实非常直接，我通常会用几个简单的命令来快速确认。这就像是装了新轮胎后，总要踩两脚油门看看是不是真的能跑一样。
-
检查
java命令的版本： 这是最基本的检查。在终端中输入：java -version
这个命令会输出当前
java命令所指向的JDK版本信息。我会仔细核对输出中的版本号（例如openjdk version "11.0.12"或java version "1.8.0_202"），确保它与我期望切换到的版本一致。 -
检查
javac命令的版本（如果需要编译）： 如果你是开发者，并且需要使用Java编译器javac，那么也应该检查它的版本：javac -version
理论上，
java和javac应该指向同一个JDK版本。如果它们不一致，那说明你的update-alternatives配置可能不完整，或者PATH环境变量中javac的优先级不对。这种情况我遇到过，通常是忘记对javac也执行update-alternatives --config javac。 -
检查
JAVA_HOME环境变量（如果通过环境变量切换）： 如果你是通过设置JAVA_HOME来切换的，那么检查这个变量的值是否正确指向了目标JDK的安装路径也是很重要的：echo $JAVA_HOME
输出的路径应该和你设置的
JAVA_HOME路径完全一致。同时，也可以检查PATH变量，确保$JAVA_HOME/bin位于$PATH的靠前位置，这样系统才能优先找到你指定版本的Java可执行文件。echo $PATH
这些检查能让我快速判断切换是否成功，并定位可能出现的问题。
除了手动配置，还有哪些工具可以简化Java版本管理？
除了上面提到的 update-alternatives 和手动设置环境变量，市面上还有一些非常实用的工具可以大大简化Java版本的管理。对我来说，这些工具简直是开发者的福音，尤其是在需要频繁切换不同Java版本时。
SDKMAN! (Software Development Kit Manager)
这是我最常用，也是最推荐的一个工具。SDKMAN! 的设计理念就是为了让开发者能够轻松地安装、切换和管理各种SDK，其中就包括了Java（各种JDK发行版）、Maven、Gradle、Kotlin、Scala等等。
它的优点非常突出：
-
一键安装和切换： 你可以通过简单的命令安装多个Java版本，然后用一个命令就能在它们之间进行切换。比如，安装 OpenJDK 17：
sdk install java 17.0.9-tem，然后切换到它：sdk use java 17.0.9-tem。 - 版本隔离： SDKMAN! 会将不同版本的SDK安装到各自独立的目录，很好地避免了版本冲突。
- 易于更新和卸载： 更新到最新版本或者移除不再需要的版本都非常方便。
- 跨平台： 尽管这里讨论的是Linux，但SDKMAN! 也支持macOS和Windows (通过WSL)。
它的安装也很简单，通常只需要一行curl命令：
curl -s "https://get.sdkman.io" | bash
然后按照提示操作，重启终端即可使用。
asdf-vm
asdf-vm 是另一个类似的工具，它通过插件系统来管理各种运行时版本，Java只是其中之一。它的通用性更强，不仅仅局限于SDK，还可以管理Node.js、Python、Ruby等多种语言的运行时。如果你同时开发多种语言的项目，asdf-vm 可能会更吸引你。
使用 asdf-vm 管理Java的流程大致是：
- 安装 asdf-vm 本身。
- 安装 Java 插件：
asdf plugin add java。 - 安装特定Java版本：
asdf install java openjdk-17.0.9。 - 设置全局或局部Java版本：
asdf global java openjdk-17.0.9或在项目目录下asdf local java openjdk-11.0.2。
asdf-vm 的优点在于其高度的灵活性和对多语言环境的支持。它通过 .tool-versions 文件在项目级别管理版本，非常适合团队协作和CI/CD流程。
对我来说，SDKMAN! 更专注于SDK管理，界面和命令更直观，而 asdf-vm 则更通用，适合管理所有类型的运行时。具体选择哪个，就看个人的偏好和项目需求了。但无论哪个，它们都比手动管理环境变量或 update-alternatives 要省心得多。
