导语：
截至 2026 年 3 月 12 日，Java 平台团队正处在一个很典型的升级窗口。OpenJDK 2026-01-20 安全公告给出了明确的风险收敛压力；Spring Boot 3.5.11 已在 2 月 19 日发布；GitHub CodeQL 2.24.3 则在 3 月 10 日新增 Java 26 支持，并改进多模块 Maven 项目的版本选择逻辑。与此同时，OpenJDK 质量邮件中已经明确 JDK 26 预计于 2026 年 3 月 17 日 GA，HTTP/3 等能力也意味着后续验证工作要提前做。
这组信息放在一起，给 Java 团队的要求很简单：不要再把升级看成“安全团队催一次、业务团队推一次”的临时动作，而要把它做成固定节奏。
1. 当前 Java 升级为什么经常难推进
- 原因一：版本长期漂移，服务之间差异过大。
- 原因二：只看漏洞，不看运行时兼容与性能副作用。
- 原因三：没有回滚预案，团队对发布窗口天然保守。
2. 适合 2026 年的双轨治理模型
- 安全轨
优先解决已披露高风险问题，缩短暴露窗口。 - 稳定轨
验证 JDK、Spring Boot、依赖升级后的性能、兼容和异常路径。
安全轨负责“快”，稳定轨负责“稳”，两条线必须并行。
3. 推荐执行流程
- 盘点版本
统计 JDK、Spring Boot、核心依赖、构建插件版本。 - 做影响分层
按公网暴露、业务关键性、流量峰值划分优先级。 - 建立目标版本
确定短期安全基线和中期升级基线。 - 接入静态分析
在 CI 中使用 CodeQL 与 SCA 做前置检查。 - 补齐回归
覆盖线程池、序列化、连接池、TLS、GC、HTTP 客户端行为。 - 做压测
验证升级后 P95、P99、内存、错误率、启动时间变化。 - 分区灰度
从低风险服务到核心服务逐级推进。 - 自动回滚
把错误率、线程池拒绝率、超时率写成硬阈值。 - 更新台账
确保报告版本和运行版本一致，避免“文档已升级、镜像未升级”。
4. 建议团队重点关注的校验点
- Maven 多模块项目的 JDK 选择是否一致。
- Java 26 相关编译链能否被扫描工具正确识别。
- Spring 版本升级是否引入默认配置变化。
- 内部 HTTP 客户端未来迁移到 HTTP/3 能力时的兼容测试脚本是否就绪。
5. 指标建议
- 高危漏洞修复时长。
- Java 服务版本一致率。
- 升级后 24 小时错误率。
- 回滚触发次数与恢复时间。
- 升级任务按计划完成率。
6. 结语
Java 团队的成熟度，不体现在“某次升级做得多漂亮”，而体现在“升级是否可重复、可度量、可回滚”。到 2026 年 3 月，这已经是平台工程的基本功，而不是加分项。
参考资料
- OpenJDK Vulnerability Advisory: 2026/01/20
https://openjdk.org/groups/vulnerability/advisories/2026-01-20 - Spring Boot 3.5.11 available now（2026-02-19）
https://spring.io/blog/2026/02/19/spring-boot-3-5-11-available-now - GitHub Changelog: CodeQL 2.24.3 adds Java 26 support and other improvements（2026-03-10）
https://github.blog/changelog/2026-03-10-codeql-2-24-3-adds-java-26-support-and-other-improvements - OpenJDK Quality Outreach: JDK 26 Feature Freeze, HTTP/3, and more Heads-Ups
https://mail.openjdk.org/pipermail/quality-discuss/2025-December/001146.html
