Java启动时加载的JDK取决于PATH中首个java可执行文件所在路径，再反推其JDK根目录；JAVA_HOME不参与java命令调用，但被Maven等工具链直接读取。
Java 启动时用的是哪个 JDK？看 JAVA_HOME 和 PATH 的配合顺序
Java 进程启动时到底加载哪个 JDK，不取决于你装了几个，而取决于系统在 PATH 中第一个找到的 java 可执行文件，再反查它所属的 JDK 根目录（即 JRE_HOME 或隐式推导出的 JDK_HOME）。JAVA_HOME 本身并不直接参与 Java 命令调用，但它会被很多工具链（如 Maven、Tomcat、IDE）主动读取并用于定位工具类库或编译器。
常见错误现象：java -version 显示是 JDK 17，但运行 mvn compile 却报 Unsupported class file major version 61（即 Maven 内部用了 JDK 11 编译）——说明 Maven 没走 PATH，而是自己去读 JAVA_HOME，而这个环境变量还指向旧版本。
-
JAVA_HOME应始终指向你希望构建/编译使用的 JDK 根目录（比如/usr/lib/jvm/jdk-17.0.2），不是bin子目录 -
PATH必须把$JAVA_HOME/bin放在最前面，否则终端敲java可能调到系统自带或 brew 安装的老版本 - macOS 上注意：GUI 应用（如 IntelliJ）可能不继承 shell 的
PATH，需通过launchctl setenv JAVA_HOME ...或修改~/.zprofile并重启 Dock
IDEA / Eclipse 启动失败报 “JDK path is not valid” 或黑屏闪退
这类问题几乎全是 IDE 自己的启动脚本绕过了系统 PATH，转而依赖硬编码或配置文件里的 JDK 路径。尤其 macOS 的 .app 包会自带一个 Info.plist，里面可能写死了 JVMVersion 或 JVMHome。
典型表现：终端里 java -version 正确，但双击 IDEA 图标就卡住或弹错；或者项目能编译，但调试器连不上（Unable to open debugger port）。
- IntelliJ：检查
Help → Edit Custom VM Options...，确认没写死-Didea.jdk=...；再打开Help → About → System Properties，找java.home值是否和你预期一致 - Eclipse：启动时加
-vm参数强制指定，比如eclipse -vm /opt/jdk-17/bin/java；避免依赖eclipse.ini里模糊的-vmargs - Windows 用户注意：
JAVA_HOME路径含空格（如C:\Program Files\Java\jdk-17）必须用短路径（C:\Progra~1\Java\jdk-17）或引号包裹，否则某些批处理脚本会截断
Linux 下多 JDK 共存时，update-alternatives 怎么设才不翻车
Debian/Ubuntu 系统用 update-alternatives 管理多版本 Java 是最稳妥的方式，但它只改 /usr/bin/java 这个符号链接，不碰 JAVA_HOME —— 所以你得手动同步设置，否则工具链会分裂。
容易踩的坑：sudo update-alternatives --config java 切换后，mvn -v 仍显示旧版本 JDK，因为 Maven 优先读 JAVA_HOME，而这个变量没变。
- 先用
update-alternatives --install注册所有 JDK 的java、javac、jar命令（别漏掉javac！否则编译报错） - 切换后立刻执行：
export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:/jre/bin/java::;s:/bin/java::")（适用于标准安装结构） - 把
JAVA_HOME写进/etc/environment（全局）或~/.profile（用户级），别只写在~/.bashrc里——后者对非交互式 shell（如 cron、CI 脚本）无效
Docker 构建中 JDK 版本混乱：基础镜像 vs 构建阶段 vs 运行时
Dockerfile 里写 FROM openjdk:17-jdk-slim，结果 docker run -it myapp java -version 却显示 11 —— 很可能是你在构建阶段用了 multi-stage，但 final 阶段 COPY 了错误的 JRE，或者 base 镜像被中间层覆盖了 PATH。
另一个高频问题：Spring Boot fat jar 在容器里启动报 java.lang.UnsupportedClassVersionError，但本地跑得好好的 —— 容器内实际运行的 JDK 版本低于编译版本。
- 构建阶段（
build）用高版本 JDK（如 17）编译，final 阶段（runtime）也必须用 ≥17 的 JRE，不能为了镜像小就降级成openjdk:11-jre-slim - 显式声明
ENV JAVA_HOME=/opt/java/openjdk并ENV PATH=$JAVA_HOME/bin:$PATH，避免依赖镜像默认的软链接逻辑 - 如果用
gradle:jdk17作为构建镜像，注意它自带的gradlewrapper 可能默认调用/opt/java/openjdk/bin/java，但你的build.gradle若写了javaToolchain { version = "11" }，就会强行降级编译
最麻烦的其实是跨平台开发：Mac 上用 Zulu JDK 17 编译，Linux CI 用 OpenJDK 17 构建，但两者 java.home 路径结构不同，导致打包插件（如 jlink）生成的运行时路径失效。这种细节没法靠统一环境变量兜底，得在构建脚本里做路径探测。
