多版本JDK切换方法详解

切换默认Java版本需调整JAVA_HOME和PATH环境变量，确保目标JDK的bin目录优先加载。Windows用户通过系统属性修改环境变量并调整Path顺序，Linux/macOS用户则在shell配置文件中设置export JAVA_HOME和PATH，并用source生效；也可使用SDKMAN!、jEnv等工具实现自动化管理，提升多版本切换效率。

多版本JDK共存时，切换默认Java版本主要围绕着操作系统环境变量的调整，尤其是JAVA_HOME和PATH这两个核心变量。其本质是告诉你的系统和应用程序，当前应该优先使用哪一个Java开发工具包。这通常不是一个复杂的操作，但如果处理不当，可能会导致一些莫名其妙的构建失败或运行时错误，让人头疼。

解决方案

要切换默认的Java版本，核心操作是修改系统的环境变量。这在不同操作系统上略有差异，但目标都是将你希望使用的JDK路径设置为JAVA_HOME，并确保这个JDK的bin目录在系统PATH变量的前面，这样当系统查找java或javac命令时，会优先找到你指定版本的。

在Windows环境下：

1. 找到你的JDK安装路径： 比如 C:\Program Files\Java\jdk-17.0.2 或 C:\Program Files\Java\jdk-8u311。
2. 打开环境变量设置： 右键“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。
3. 设置JAVA_HOME：
   • 在“系统变量”中，查找JAVA_HOME变量。如果不存在，点击“新建”；如果存在，点击“编辑”。
   • 将变量值设置为你希望使用的JDK的安装路径（例如，C:\Program Files\Java\jdk-17.0.2）。
4. 修改Path变量：
   • 在“系统变量”中，找到Path变量，点击“编辑”。
   • 你会看到一串路径列表。找到或新建一个指向%JAVA_HOME%\bin的条目。
   • 关键一步： 确保%JAVA_HOME%\bin这个条目在所有其他可能指向Java安装路径的条目（比如C:\Program Files\Common Files\Oracle\Java\javapath，这是Java安装器有时会添加的）的前面。你可以通过上下移动来调整顺序。
5. 验证： 打开一个新的命令提示符（旧的可能不会立即生效），输入 java -version 和 javac -version，检查输出是否为你期望的JDK版本。

在Linux/macOS环境下：

1. 找到你的JDK安装路径： 比如 /usr/lib/jvm/java-11-openjdk-amd64 或 /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home。
2. 编辑你的shell配置文件： 通常是 ~/.bashrc、~/.zshrc 或 ~/.profile。使用你喜欢的文本编辑器打开它，例如 nano ~/.bashrc。
3. 添加或修改环境变量：

   # 设置JAVA_HOME为目标JDK路径
   export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home
   # 将JAVA_HOME/bin添加到PATH变量的开头
   export PATH=$JAVA_HOME/bin:$PATH

   如果你有多个JDK，你可以在这里注释掉不用的，或者使用条件判断。

4. 使配置生效： 保存文件后，在终端中运行 source ~/.bashrc (根据你修改的文件名来定)。
5. 验证： 输入 java -version 和 javac -version，检查输出。你也可以运行 echo $JAVA_HOME 来确认 JAVA_HOME 的值。

对于Linux系统，尤其是基于Debian/Ubuntu的发行版，还有一个系统级的工具 update-alternatives 可以管理默认的Java版本。你可以使用 sudo update-alternatives --config java 和 sudo update-alternatives --config javac 来选择系统默认的Java执行文件。这种方式是系统全局的，可能会覆盖用户环境变量设置，具体取决于你的shell配置和系统PATH变量的解析顺序。

为什么我的系统里会有多个JDK版本，以及这会带来什么问题？

这几乎是每个Java开发者都会遇到的“甜蜜烦恼”。系统里有多个JDK版本，原因其实挺多的。最常见的是，你可能在维护多个项目，而这些项目各自依赖于不同的Java版本。比如，一个老旧的遗留系统可能还跑在Java 8上，而你新开发的服务则使用了Java 17甚至更新的版本，因为它能带来性能提升和新的语言特性。有时候，IDE（比如IntelliJ IDEA）为了自身的运行或方便管理，也会自带或推荐安装特定的JDK版本。甚至有些第三方工具或框架在安装时，也会顺手给你装一个它觉得“合适”的JDK。

这种多版本共存本身不是问题，问题在于“默认”这个概念。当你的系统需要执行一个Java程序，或者你敲下 java -version 命令时，它需要知道去哪里找这个 java 可执行文件。如果你的环境变量配置不清晰，或者有多个路径都指向了Java的安装目录，系统就会根据 PATH 变量的顺序，找到它遇到的第一个 java。

这就会导致一系列问题：

• 版本混淆： 你以为你用的是Java 17，结果 java -version 出来却是Java 8，这就很尴尬了。
• 构建失败： Maven或Gradle项目在编译时，可能依赖于某个特定版本的 javac。如果 javac 版本不对，轻则编译警告，重则直接报错，因为语法特性不兼容。
• 运行时错误： 某些应用程序可能在特定JDK版本下才能正常运行，如果使用了错误的JDK，可能会出现类找不到（ClassNotFoundException）或者方法签名不匹配（NoSuchMethodError）等运行时异常。
• IDE配置困扰： 虽然IDE通常可以为每个项目单独配置JDK，但如果系统默认的JDK不对，新项目创建时可能会默认选择错误的JDK，或者在命令行工具与IDE之间切换时产生不一致。

所以，清晰地管理和切换JDK版本，是保证开发环境稳定和项目顺利进行的关键。

在Windows和Linux/macOS环境下，具体操作步骤是怎样的？

前面在解决方案部分已经简要提到了，这里我们再深入一点，加入一些实际操作中可能遇到的细节和最佳实践。

Windows环境下的细节与考量：

在Windows上，环境变量的设置是全局性的，这意味着一旦你修改了JAVA_HOME和Path，所有新的命令行窗口都会受到影响。

1. 关于Path变量的顺序： 这是Windows上最容易出错的地方。Windows的Path变量是按顺序查找的。如果你将%JAVA_HOME%\bin放在了其他Java相关路径（例如 C:\Program Files\Common Files\Oracle\Java\javapath，这个路径是Oracle Java安装时为了方便而添加的，它指向了当前系统默认的Java可执行文件）的后面，那么系统仍然会优先找到旧的Java。所以，务必将你想要的%JAVA_HOME%\bin移动到列表的最顶部，或者至少在所有其他Java相关路径的前面。
2. 用户变量 vs. 系统变量： 你也可以在“用户变量”中设置JAVA_HOME和Path。用户变量只对当前登录的用户生效，而系统变量对所有用户生效。通常，为了避免冲突和保持一致性，我们倾向于修改“系统变量”。但如果你是多用户系统，且每个用户需要不同的默认JDK，那么用户变量会是更好的选择。
3. 重启命令行： 修改环境变量后，务必关闭所有已打开的命令提示符或PowerShell窗口，然后重新打开。否则，它们会沿用旧的环境变量配置。IDE通常也需要重启才能识别新的系统环境变量。

Linux/macOS环境下的细节与考量：

在Unix-like系统上，环境变量的设置通常是通过shell配置文件（如.bashrc, .zshrc, .profile）进行的，这使得切换更加灵活，但也可能因为配置文件的加载顺序而变得复杂。

1. 选择正确的配置文件：
   • ~/.bashrc: Bash shell交互式非登录会话（最常用）。
   • ~/.zshrc: Zsh shell交互式非登录会话。
   • ~/.profile / ~/.bash_profile: 登录会话（可能在~/.bashrc之前加载，如果两者都存在，通常~/.bash_profile会加载~/.bashrc）。
   • ~/.zshenv: Zsh shell的每个会话（登录和非登录）都会加载。 通常，在~/.bashrc或~/.zshrc中设置是比较常见的做法。
2. export 命令： 记得使用 export 关键字，这样变量才能被子进程继承。
3. PATH 变量的添加顺序： export PATH=$JAVA_HOME/bin:$PATH 这种写法将$JAVA_HOME/bin放在了现有PATH的前面，确保了优先级。这是推荐的做法。
4. source 命令： 修改配置文件后，需要使用 source 命令（或 .）来重新加载它，让更改立即生效，例如 source ~/.bashrc。
5. update-alternatives (仅限Debian/Ubuntu)：
   • 这是一个系统级的符号链接管理工具。你可以用它来注册不同的Java版本：

     sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1
     sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-17-openjdk-amd64/bin/java 2

     这里的数字 1 和 2 是优先级，数字越大优先级越高。

   • 然后通过 sudo update-alternatives --config java 进行选择。
   • 注意： 这种方式修改的是系统默认的 /usr/bin/java 符号链接。如果你的shell配置文件中设置了JAVA_HOME和PATH，且优先级更高，那么你的用户配置会覆盖 update-alternatives 的设置。理解这种优先级关系很重要。

有没有更优雅或自动化的方式来管理和切换JDK版本？

当然有！对于频繁需要在多个JDK版本之间切换的开发者来说，手动修改环境变量很快就会变得枯燥且容易出错。幸运的是，社区提供了非常优秀的工具来解决这个问题。

1. SDKMAN! (Software Development Kit Manager)

   • 适用平台： Linux, macOS, WSL。
   • 特点： 这是一个非常流行的命令行工具，不仅可以管理Java（包括各种JDK发行版如OpenJDK, GraalVM等），还能管理Groovy, Kotlin, Scala, Maven, Gradle等几乎所有JVM生态工具链。
   • 使用方式：
     • 安装：curl -s "https://get.sdkman.io" | bash
     • 列出可用Java版本：sdk list java
     • 安装指定版本：sdk install java 17.0.2-tem (例如安装Temurin 17.0.2)
     • 切换默认版本：sdk use java 17.0.2-tem (当前shell会话生效) 或 sdk default java 17.0.2-tem (全局默认)
   • 个人看法： 我个人非常推荐SDKMAN!。它极大地简化了安装和切换过程，尤其是在你需要尝试不同JDK发行版或新版本时，简直是开发者的福音。

2. jEnv

   • 适用平台： Linux, macOS。
   • 特点： 专注于Java版本管理，可以为每个项目目录设置独立的Java版本，类似于rvm或nvm。
   • 使用方式：
     • 安装：通常通过Homebrew (brew install jenv) 或手动克隆GitHub仓库。
     • 将JDK添加到jEnv：jenv add /path/to/jdk-17.0.2
     • 列出已添加的JDK：jenv versions
     • 设置全局默认版本：jenv global 17.0.2
     • 设置当前目录版本：进入项目目录，运行 jenv local 11.0.10
   • 个人看法： jEnv在多项目开发中非常有用，特别是当每个项目严格绑定特定JDK版本时。它能确保你进入特定项目目录时，自动使用该项目所需的JDK，避免了手动切换的麻烦。

3. IDE内置的JDK管理

   • 特点： 几乎所有现代Java IDE（如IntelliJ IDEA, Eclipse, VS Code with Java extensions）都允许你为每个项目独立配置JDK。
   • 使用方式： 在项目设置中，找到“Project Structure”或“Java Build Path”，然后指定项目使用的JDK路径。
   • 个人看法： 这是最常见的项目级JDK管理方式。即使你使用了SDKMAN!或jEnv来管理系统或全局的JDK，IDE的这个功能仍然非常重要，因为它能确保项目在IDE内部编译和运行时，使用的是正确的JDK版本，而不会受到系统环境变量的干扰。这通常是开发中最高优先级的JDK设置。

这些工具和IDE功能的存在，使得多版本JDK共存不再是噩梦，反而能让开发者更灵活、高效地应对不同项目的需求。选择哪种方式，取决于你的工作流和对自动化程度的要求。对于我来说，SDKMAN!结合IDE的项目级设置，基本能覆盖所有场景了。