小范围上线需隔离而非替代，应通过软链接+用户级环境变量+启动脚本硬编码三层兜底，避免修改全局java_home影响jenkins等依赖旧jdk的服务。
为什么不用全局替换 JAVA_HOME
直接改 JAVA_HOME 或系统级 /etc/profile.d/java.sh 会影响所有服务，比如正在跑的 Jenkins、ZooKeeper、旧版 Spring Boot 应用——它们可能依赖 JDK 8 的 TLS 协议栈或 javax.* 包。小范围上线的核心是「隔离」，不是「替代」。
用软链接 + 用户级环境变量做灰度切换
在目标用户（如部署脚本运行账户）的家目录下操作，不碰系统全局配置：
- 把新 JDK（比如 Eclipse Temurin JDK 21）解压到
/opt/jdk/temurin-21.0.5+11，路径不含空格和中文 - 在该用户 home 下建软链：
ln -sf /opt/jdk/temurin-21.0.5+11 ~/jdk21 - 编辑
~/.bashrc，末尾加三行：export JAVA_HOME=$HOME/jdk21export PATH=$JAVA_HOME/bin:$PATHexport JAVACMD=$JAVA_HOME/bin/java - 执行
source ~/.bashrc，再验证：java -version应输出 21.x，且which java指向~/jdk21/bin/java
启动脚本里显式指定 java 路径更可靠
哪怕环境变量设对了，某些 Java 进程（如 systemd service、cron job）可能不读 ~/.bashrc。最稳妥的方式是在启动命令里硬编码路径：
- 写一个 wrapper 脚本
start-app.sh：#!/bin/sh/home/deploy/jdk21/bin/java -jar /opt/myapp/app.jar - 用
nohup启动时也带上完整路径：nohup /home/deploy/jdk21/bin/java -Xms512m -Xmx2g -jar app.jar & - Tomcat 可在
bin/setenv.sh里写：export JAVA_HOME=/home/deploy/jdk21
验证时别只信 java -version
很多应用实际调用的是 javac 或 keytool，而这些命令可能被 PATH 里其他 JDK 的 bin 目录抢先命中。上线前必须检查：
-
which javac和which keytool是否都指向新 JDK 的bin/目录 - 运行
/home/deploy/jdk21/bin/java -cp . TestClass手动编译+执行一个含System.getProperty("java.version")的测试类 - 如果应用用 Maven 构建，确认
mvn -v输出的 Java 版本与预期一致——Maven 会读JAVA_HOME，但有时会 fallback 到PATH中第一个java
真正的小范围上线，关键不在“装新 JDK”，而在“让特定进程只看到它”。软链 + 用户级变量 + 启动脚本硬编码，三层兜底，比改系统配置安全得多。最容易被忽略的是：没验证 javac 和 keytool 是否同步切换，结果编译成功但证书生成失败，卡在部署后一步。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
