先确认启动日志和当前JDK版本
升级Jenkins后若在启动日志中看到类似“Unsupported Java Version”或“requires Java 11 or newer”的提示，通常在Jenkins的启动脚本或系统服务配置中绑定了旧版Java路径。此时应先用`java -version`确认当前默认JDK版本，再检查`/etc/init.d/jenkins`或`/etc/sysconfig/jenkins`等配置文件中的`JAVA_HOME`变量是否还指向旧版本的安装目录。
这里建议不要一看到提示就立刻安装新版JDK。先确认当前默认JDK版本是为了区分两种常见情况：一是系统默认Java已经符合要求，只是Jenkins服务脚本里显式指定了旧路径；二是系统默认Java本身还是旧版，需要整体升级。两种情况的处理方式不同，前者只需要改Jenkins的配置，后者则要安装新JDK并调整全局路径。另外，要注意`java -version`输出的是shell环境下的版本，而Jenkins服务可能通过init脚本或systemd服务文件读取的是另一个JAVA_HOME，所以这个命令只能作为参考，关键还是要看配置文件里写的是什么。
容易误判的几种情况
常见的坑包括：只修改了`java`命令的软链接，但Jenkins自身调用`javac`或`jrunscript`时仍然失败；或者配置文件中有多个JAVA_HOME定义，后加载的覆盖了前面的。另一个容易忽略的是Windows环境下升级后，“Jenkins”服务在“服务管理”里仍然绑定旧JVM路径，需要运行`tomcat8w`之类的工具重新指向新安装的JDK。若升级前使用了`java.opt`参数，升级后必须逐一核对，某些旧参数在新JDK中已被移除，会导致启动直接崩溃。
这些情况有个共同点：表面上看`java -version`已经对了，但Jenkins实际启动时使用的环境变量或参数仍来自旧的配置。比如只修改了/usr/bin/java的软链接，但Jenkins脚本里写的是绝对路径，或者通过JAVA_HOME拼接出javac路径，这样就不会生效。所以排查时要把服务启动脚本、systemd unit、环境变量文件和Jenkins自身的配置都检查一遍，不能只看一个位置。
建议的处理顺序
先确认新版本Jenkins要求的Java最低版本，再调整JAVA_HOME。例如，如果当前系统存在多个JDK，可以在启动前显式设置`JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64`，同时更新PATH变量。修改后不要直接重启，先运行`jenkins --version`测试是否能正常加载，避免因环境变量错误导致服务反复重启。
这个顺序的核心是先验证再重启。很多人在修改配置文件后习惯立刻`systemctl restart jenkins`，但如果JAVA_HOME写错，服务会进入重启循环，反而更难排查。先用`jenkins --version`做冒烟测试，能快速确认环境变量是否被正确读取。注意这个命令需要以运行Jenkins的用户身份来执行，否则可能读到当前用户自己的JAVA_HOME，而不是服务用户的环境。如果服务是通过systemd运行的，可以先用`systemctl show jenkins --property=Environment`查看实际加载的环境变量。
检查配置文件与命令示例
在调整JAVA_HOME之前，先检查Jenkins实际读取的是哪个配置文件。对于systemd系统，使用systemctl cat jenkins查看ExecStart行，确认是否硬编码了Java路径。对于传统init脚本，查看/etc/init.d/jenkins和/etc/sysconfig/jenkins。还可以用readlink -f $(which java)确认命令实际指向。
一个常见的做法是创建一个独立的配置文件给Jenkins使用，避免污染系统级环境变量。例如在/etc/sysconfig/jenkins里只设置JENKINS_JAVA_CMD或JAVA_HOME，而不是修改全局/etc/profile。这样即使其他应用依赖旧版JDK，也不会被Jenkins的改动影响。对于手动解压的Jenkins发行版，可以修改jenkins.sh脚本，在脚本开头显式export JAVA_HOME。
验证与回滚边界
完成修改后，除了运行jenkins --version，还可以先启动一次服务并观察日志输出。使用journalctl -u jenkins -f可以实时查看启动日志，确认没有出现ClassNotFoundException或UnsupportedClassVersionError。如果启动失败，先不要急着反复重启，检查错误日志中提到的类或模块，再决定是调整JAVA_HOME还是增加JVM参数。
回滚也很简单：在修改配置前把原文件备份一份，例如cp /etc/sysconfig/jenkins /etc/sysconfig/jenkins.bak。如果新配置导致服务起不来，直接恢复备份即可。需要留意的是，如果同时更换了JDK安装包，回滚时也要把JAVA_HOME指回原来的JDK目录，不能只恢复配置文件。
后续维护：插件与全局变量
升级Java版本时，注意Jenkins插件可能对JDK有额外兼容性约束。例如，部分旧插件在JDK 17下会因模块访问限制报错，此时可考虑使用“--add-opens”启动参数，但不要随意添加所有JVM参数，以免掩盖真实问题。同时，若系统同时运行其他依赖Java的应用，修改全局JAVA_HOME可能影响它们，建议在Jenkins启动脚本中单独定义环境变量，而不是改动系统级配置。
除此之外，升级后还要留意Jenkins的更新中心提示。有些插件本身会声明最低Java版本，如果某个插件在升级后失效，先查看该插件的更新日志，确认是否支持当前JDK。不建议为了兼容旧插件而长期停留在旧JDK上，那样新版本Jenkins可能无法获得安全更新。如果必须使用旧JDK，则要考虑升级Jenkins到支持该JDK的最后一个版本，但这属于另一种权衡，需要结合环境确认。