你家的 Jenkins 还跑在 Java 17 上？最新 LTS 已把门槛抬到 21，升级前先看这篇_软件技能

如果你公司的 Jenkins 还跑在 Java 17 上，而且你最近有任何升级 LTS 的打算，这篇值得花五分钟看完。不是贩卖焦虑，是 2026 年年中这条时间线上，Jenkins 的 Java 门槛真的变了，而且改得很硬。

一条真实的报错日志

6 月份有位做 Jenkins 实战记录的网友，在华为云 ECS 上装 Ubuntu 24.04 + Jenkins 2.555.2 LTS，启动直接失败，报错原文是：

Running with Java 17, which is older than the minimum required version (Java 21)。Supported Java versions are: [21, 25]

注意这个坑有多顺手：Ubuntu 24.04 默认 apt 装出来的就是 Java 17，也就是说，你用一台全新的主流系统服务器，按老习惯装最新版 Jenkins LTS，它会直接拒绝启动。知乎最后的解法很简单，`apt-get install openjdk-21-jre` 换掉 JVM 就好——但如果你是在生产环境的升级窗口里撞上这一行字，味道就完全不一样了。

这不是个例。2026 年 2 月，社区里就有人提醒：Jenkins 官方已经在明确传递"Java 17 逐步不再被支持"的信号，新项目建议直接上 JDK 21。知乎到了年中的 LTS 版本，这个信号已经落地成了启动时的硬性校验。

Jenkins 的 Java 版本线，是怎么一步步挪过来的

给不太追版本的同学补一下背景，Jenkins 对 Java 的要求这几年一直在往上抬：

早年 Java 8 跑一切；
2022 年前后，Java 11 成为控制器的最低要求；
2023 年起，Java 17 成为最低要求，Java 21 开始被支持；
2026 年年中的 LTS 线（如 2.555 系列），最低要求抬到 Java 21，同时已经把 Java 25 也列入支持列表。

规律很清楚：每隔两年左右，Jenkins 就会把 Java 底线抬一代，而且一旦抬了就不回头。所以现在还在 Java 17 上"稳如老狗"的实例，不是要不要升的问题，是什么时候升、怎么升不炸的问题。

"留在老版本不动"行不行？算一笔账

社区里最真实的心态是：现在跑得好好的，不升不就没这些事了？这个想法可以理解，但有三笔成本要摊开看。

第一笔是安全修复。Jenkins 的安全公告发布频率不低，修复几乎都跟着新版本走，老版本等不到回迁。你停留在旧 LTS 上，等于主动放弃了后面所有安全补丁，而 Jenkins 偏偏是个握着代码仓库凭据、SSH 密钥、部署 Token 的角色，它被打穿的后果比普通业务服务严重得多。

第二笔是插件生态。新插件的版本要求只会往上走，不会往下兼容。已经有面向多实例同步的新插件把门槛标到 Jenkins 2.479.2、Java 17 以上，未来只会有更多插件把 Java 21 当默认前提。知乎等你哪天必须装某个插件时，补升级就是被动局。

第三笔是收益本身就在那摆着。Jenkins 自己的官方基础设施从 Java 17 升到 Java 21 之后，月度平均内存占用从 33-34GB 降至 28GB，省了大约 15-18%，而且没有改任何应用层代码，纯粹是 JVM 运行时和 GC 改进带来的。知乎对中小实例来说，这基本等于白捡一档内存规格，或者把 Master 从内存飘红的边缘拉回来。

怎么升才不炸：社区两年踩坑换来的纪律

7 月有篇企业级 Jenkins 踩坑复盘很值得参考，他们团队扛日均 2000+ 构建，总结出来的升级纪律可以直接抄：

Jenkins 核心升级和插件升级分开做，别赶在同一天，出了问题都不知道找谁；
任何核心版本变更，先在测试环境完整验证一遍，包括启动、登录、Agent 连接、跑一遍主力流水线；
动 JENKINS_HOME 之前先做完整备份。Jenkins 的数据结构对降级很不友好，备份是你唯一的后悔药；
老案例反复提醒：先查清楚目标版本对应的 JDK 要求再动手。

具体到这次 Java 17 → 21，不同部署方式的动作不太一样：

Docker 部署的：检查你现在用的镜像 tag。如果还钉在 `jenkins/jenkins:lts-jdk17` 这类 Java 17 变体上，规划换成默认 tag（当前 LTS 已是 Java 21 底座）或 `lts-jdk21` 变体。换 tag 前先确认挂载的 JENKINS_HOME 数据卷没动，插件目录是跟着卷走的。

包管理 / WAR 部署的：先把 openjdk-21 装上，用 `java -version` 和 alternatives 机制确认服务实际拉起的是 21，再去升 Jenkins 核心。顺序反了，就是文章开头那行报错。注意 JVM 参数（比如 `-Xms`/`-Xmx`、GC 配置）如果写在 JENKINS_JAVA_OPTIONS 里，换 JDK 后记得复查一遍，别把旧参数当默认值带进去。

升完之后的验证清单：启动日志无异常 → 内置节点和所有 Agent 在线 → 跑一遍最有代表性的流水线（构建、推镜像、部署各来一次）→ 观察一两天构建时长和内存曲线。用 K8s 动态 Agent 的团队，Agent 镜像里的 JDK 也要一并规划，别只换控制器。

升失败了怎么办：回滚靠的是升级前的 JENKINS_HOME 备份和旧版本包，所以备份这一步真的不能省。宁可多花二十分钟备份，也不要赌"应该不会出问题"。核心升级与插件升级分离、测试环境先验证这两条纪律，是社区用真实生产事故换来的。知乎

三类人，三种动作

生产实例还在 Java 17、近期不打算动功能：不急着今天动手，但把"JVM 换 21"排进这个季度的维护窗口，测试环境先趟一遍。拖着不升的最大风险不是今天，是你某天被迫紧急升级时没有演练过。
Docker 钉着 lts-jdk17 tag 的：先看一眼当前实际跑的版本号，如果已经是较新的 LTS 线却还能启动，说明 tag 钉住了旧版本——把换 tag 和升版本当成一次变更一起规划，别拆成两次惊吓。
准备新装 Jenkins 的：直接 Java 21 起步，别碰 17。尤其是 Ubuntu 24.04 用户，默认装出来的 Java 17 就是个现成的坑。