★ FEATURED ARTICLE 最近我们团队把核心交易链路从 JDK 21 一路升级到了 JDK 26前后折腾了大半个月。整个过程最花时间的不是写代码而是性能摸底、兼容性排查和灰度验证这三件事。这篇文章就把这次 JDK 21 升级 26 实战里最值钱的部分拆出来讲升级理由怎么量化、性能对比怎么做才靠谱、兼容问题到底集中在哪几类以及一套可以直接拿去用的灰度回滚方案。如果你正在纠结要不要升级、或者已经被升级过程中的各种诡异报错搞得焦头烂额这篇应该能帮你省下不少弯路。哪怕你手头项目还是 JDK 8 或者 JDK 11 的老古董里面排查依赖、扫描废弃 API、灰度发布的方法也完全通用。1. 为什么值得升级先算账再动手1.1 升级动机不是“新版更好”而是具体收益很多人一提升级 JDK第一反应是“团队想尝鲜”或者“技术领导追新”。其实从工程角度看这种动机撑不起一次升级带来的风险评估成本。我们这次决定升级是先在内部列了一张收益账本逐条对过业务场景后才拍的板。账本上主要集中在几个方向。虚拟线程是我们最大的诉求核心交易链路里有大量同步 IO 操作虚拟线程能把线程数从几百个压到几十个同时把吞吐拉高ZGC 分代模式在 JDK 26 里已经足够成熟GC 停顿能控制在个位数毫秒级别这对秒杀和库存场景很关键还有一些基础组件可以通过外部内存访问 API 替代原本必须借助 Unsafe 才能实现的操作安全性上升一个台阶。但也要说清楚如果你们的业务是纯计算密集型、没有高并发 IO 压力升级带来的性能收益可能非常有限。这种情况下仍然坚持升级理由就更偏向于技术栈长期维护、新特性跟进和人才吸引力属于成本账而不是收益账。升级决策一定要量化。我们把每个收益点对应到具体场景比如“虚拟线程对订单查询接口的 P99 能降低多少”这类指标等到升级完成后再回头验证。不然很容易出现升级完了大家却说不出到底哪里变好了的尴尬局面。1.2 LTS 节奏与团队升级时机判断JDK 21 本身是长期支持版本按理说可以稳稳用到很多年。为什么不等 JDK 26 变成 LTS 之后再升级这里有一个很现实的问题JDK 21 到 JDK 26 中间隔了好几个中间版本虽然每个版本变化都不算大但叠加在一起之后老的依赖生态会慢慢脱节。很多第三方库和框架在发布新版本时官方支持矩阵已经跳过了 JDK 21。这就意味着如果你长期停留在 JDK 21要么绑定在旧版本依赖上不敢动要么每次升级依赖都得小心翼翼检测兼容性。与其把自己卡在旧版本上不如选择一个跟依赖生态步伐一致的轨道。从团队节奏看升级时机通常建议选在业务低峰期。我们当时选在 Q2 中段既避开了大促节点又给后面留出了足够的灰度观察时间。不要在产品发布前夕干这事纯粹给自己找不痛快。团队内部至少要留出 3 周到 1 个月的时间盒否则遇到卡点很容易赶工出事故。另外一个判断条件是团队的技术储备。升级过程中涉及 JVM 参数调优、字节码层面排查、模块系统知识如果团队里没有人能看懂这些建议先找资深的同学做一次技术预研或者至少把风险点提前暴露出来。1.3 升级前最重要的三份清单正式动工之前我们强制自己先做三份清单。第一份是依赖清单把项目里所有直接依赖和间接依赖列出来逐一人工核对哪些库已经发布了支持 JDK 26 的版本哪些还停在旧版本。这一步听起来简单实际上非常耗时间尤其要注意那些传递依赖很多坑都是藏在一层一层传递进来的旧库里。第二份是内部代码清单用 JDK 自带的 jdeps 工具对整个应用做一次扫描专门找出代码里对 JDK 内部 API 的使用。下面是我们当时跑的基础命令jdeps --multi-release 26 --class-path target/classes:lib/* application.jar输出结果里凡是显示 JDK internal API 的条目都要逐个确认是否有替代方案。特别是sun.misc.Unsafe、com.sun.*这些内部包一旦新版 JDK 加强了封装轻则多几个启动参数重则直接 NoClassDefFoundError。第三份是 JVM 参数清单。我们收集了所有环境下的启动参数然后在新 JDK 上对比哪些参数已经废弃或失效。用下面这个命令在新版本里输出当前生效参数再跟线上参数做 diff一眼就能看出哪些配置在新版本里根本没用上java -XX:PrintFlagsFinal -version 2/dev/null | grep -E UseZGC|ConcGCThreads|MaxGCPauseMillis如果发现某些参数在 JDK 26 里已经标记为 obsolete 或者直接失效要提前更新参数模板不然上线之后你以为自己在调优其实 JVM 根本没按你的配置跑。2. 性能对比实测环境、方法与关键结论2.1 评测环境与基准设计性能对比最怕的就是环境不干净。我们专门申请了一批独立节点硬件规格统一是 8 核 16G 内存容器限制 CPU 配额避免宿主机上其他应用抢占资源导致结果失真。JDK 21 和 JDK 26 跑在完全相同的节点上中间只切换启动脚本里的 JDK 路径。评测负载我们没有用纯粹的压测工具而是录制了线上真实请求流量通过网关回放到被测应用上。回放的请求里同时包含商品详情查询、库存扣减、订单状态流转和会员信息查询四类操作尽量覆盖主链路的典型场景。每轮压测持续 30 分钟前 10 分钟作为 JIT 预热和数据缓存预热只统计后面 20 分钟的数据。除了接口维度的压测我们还专门用 JMH 写了几组微基准针对虚拟线程的创建切换开销、Vector API 在浮点计算上的增益、以及外部内存访问 API 的读写性能。微基准的价值不在数字本身而是帮助我们判断新特性到底该用到哪些模块避免在整个系统里盲目铺开。每组测试至少跑三轮取中位数作为结果。同一组测试中间还要间隔一段时间观察是否有长尾抖动。第一次跑完如果两个版本数据差异巨大先不要下结论检查是不是环境变量、JVM 参数或者 GC 策略不一致导致的。2.2 从 G1 到 ZGCGC 评测与调优GC 是这次升级里变化最直观的部分。JDK 21 时代我们主要用 G1偶尔会遇到 Full GC 引起的停顿峰值。JDK 26 给了我们一个更好的选择分代 ZGC。我们先在预发环境把小流量切到 ZGC 上跑了两周确认没有明显副作用之后才纳入正式对比。评测数据对比下来ZGC 的优势非常明显。下面是我们在同一业务压测场景下记录的 GC 指标指标JDK 21 G1JDK 26 ZGCAvg GC Pause35ms8msP99 GC Pause180ms12msFull GC 次数高频出现0吞吐量基准提升约 12%CPU 额外开销基准提升约 5%这里要特别说一句ZGC 不是万能的。如果你堆内存很小、或者应用本身几乎不产生大量垃圾ZGC 的并发处理优势体现不出来反而会带来额外的 CPU 开销。我们当时还压了一组 256M 小堆的会员服务ZGC 和 G1 的表现几乎打平后来又改回了 G1。如果你决定用 ZGC建议关注下面这几个参数。-XX:ConcGCThreads控制并发 GC 线程数默认值通常是逻辑核数的八分之一左右在容器环境下要根据 CPU 配额手动调。-XX:MaxGCPauseMillis在 ZGC 下更多是一个软约束但可以给调度器提供参考。还有 ZGC 在 JDK 26 里默认使用分代模式如果是从旧版本带过来的启动脚本记得确认没有显式关闭分代参数。2.3 业务侧的真实观测数据GC 指标只是底层表现真正让团队下定决心的是业务侧的可观测数据。我们采集了四个核心接口在同等流量下的响应时间和成功率接口JDK 21 P99JDK 26 P99提升幅度商品详情180ms95ms47%库存扣减320ms140ms56%订单创建240ms130ms46%会员查询60ms50ms17%从数据里能明显看出IO 密集型的库存扣减和订单创建提升最大。这正是虚拟线程的功劳原来一个请求要占用一个系统线程阻塞等待下游返回现在虚拟线程在阻塞时会被 JVM 自动挂起腾出执行资源给其他请求吞吐自然就上来了。有一个数据出乎我们意料会员查询这种轻量级接口也有 17% 的提升。本来以为虚拟线程和小对象分配对它没什么影响后来分析发现是 ZGC 消除了 GC 停顿尖刺P99 自然也就被拉低了。这也说明了 GC 对长尾延迟的改善是全局性的不只是高并发核心链路的利好。计算密集型的业务比如我们的价格计算服务压测结果是 JDK 26 和 JDK 21 几乎持平。Vector API 在特定算法上确实有加速但前提是代码得显式改写成向量化逻辑不改造的话 JIT 自动向量化的收益在新版本上并没有想象中那么大。3. 兼容性问题一站式解决高频问题与排查速查3.1 编译期问题内部 API、泛型推断与 Lombok升级过程中第一个撞上来的问题是编译失败。我们有两个模块直接用了sun.misc.Unsafe来做对象的浅拷贝和内存屏障JDK 26 里编译器直接把这些引用标成错误不是警告而是直接编译不过。这类问题的解法是替换 API。浅拷贝可以用标准库的Arrays.copyOf或者System.arraycopy替代内存屏障相关的逻辑如果确实绕不开就要考虑用VarHandle或者Foreign Function Memory API重写。改造量不大但需要对这个模块的实现场景有清晰理解不能只是把报错压下去。另一类编译问题是泛型推断变得更严格。很多老代码喜欢写new ArrayList().addAll(...)或者多层匿名内部类在 JDK 21 能过在 JDK 26 的编译器下会直接报“不兼容的类型”错误。这时候最省力的办法是给集合加上显式类型参数把new ArrayList()改成new ArrayListString()虽然代码看着啰嗦一点但可读性也更好。Lombok 也是绕不开的坎。老版本 Lombok 在 JDK 26 上会出现注解处理器异常甚至生成的代码字节码版本不匹配。我们统一把 Lombok 升到了较新版本同时逐个模块核对Builder、SuperBuilder这些注解生成的代码。如果你的项目里 Lombok 用得特别重建议提前在一台机器上全量跑一次编译把报错一次性收集齐。编译期还有一个隐蔽问题来自代码生成工具。我们有一个模块依赖 MapStruct升级 JDK 后注解处理器生成的代码出现了编译错误根因是 MapStruct 版本太老对新版本的javax.annotation.processing接口实现不兼容。解决办法就是老老实实升级 MapStruct没有捷径。3.2 运行期问题模块化、反射与虚拟线程陷阱编译过了只是第一关运行期才是大头。我们启动应用后遇到了第一个问题NoClassDefFoundError提示找不到某个类。排查后发现是代码直接引用了java.desktop模块里的类库而在 JDK 26 的默认模块化扫描下这个模块没有被隐式加载。解决办法是在启动脚本里显式添加模块java --add-modules java.desktop -jar application.jar这类问题用jdeps在编译期其实就能提前发现我们当时步骤没走完整结果到了启动阶段才暴露。建议大家在升级前就把jdeps的输出认认真真过一遍能省掉不少启动期的排障时间。反射相关的兼容问题也出现了。有一个模块通过反射读取了 JDK 内部类的字段JDK 21 里只需要--add-opens java.base/java.utilALL-UNNAMED就能打开但升级后发现即便加了参数某些敏感字段的访问还是被拒绝。后来查文档发现新版 JDK 对java.base里部分内部结构的保护更强了需要额外的编译期参数配合。如果你的代码里大量使用反射建议趁这次升级做一次重构把反射访问收敛到少数几个工具类里。否则以后每升级一次 JDK 都要处理一遍这类启动参数维护成本很高。虚拟线程的坑我们也踩了一个。主链路里有个老代码用synchronized关键字给一个共享对象加锁在 JDK 21 老版本虚拟线程实现里虚拟线程一旦在synchronized块内阻塞会钉住底层平台线程导致吞吐退化。新版 JDK 对锁钉住问题做了修复但在高并发场景下还是建议把synchronized块内等待下游 IO 的代码改造成ReentrantLock或者无锁设计实测吞吐能再提升一截。还有连接池的问题。虚拟线程的数量可以很大但很多老牌连接池在初始化时仍然会占用固定数量的平台线程如果线程池配置和虚拟线程数量不匹配还是会出现资源竞争。我们在升级后把连接池的最大线程数调低了一些让位给虚拟线程调度整体效果明显更平滑。3.3 中间件与框架适配清单升级过程中中间件的版本管理也是一个大工程。我们整理了当前核心链路上使用的中间件和框架逐一对照官方文档确认版本兼容情况。下面这个清单非常有用值得你参考组件类型老版本升级后版本关键变化RPC 框架老版本基于 JDK 反射新版本支持虚拟线程需开启连接复用和异步选项连接池老版本线程池固定新版本动态调整调低核心线程数消息队列客户端老版本线程模型新版本基于 NIO消费端最大并发数需重测数据库驱动老版本新版本连接属性新增了 TLS 相关参数缓存客户端老版本新版本连接超时参数单位变化其中印象最深的是数据库驱动。升级后驱动默认开始校验服务器 TLS 证书导致我们某个内网环境连接失败。排查了很久才发现是驱动新版本的安全策略变了并不是 JDK 本身的问题。这个问题也提醒我们升级 JDK 时往往会引起相关依赖的连锁升级必须把周边组件一起纳入回归范围。框架方面Spring 版本如果比较老建议至少升到支持 JDK 21 之后的版本。我们团队多个模块还在用较老的 Spring Boot升级 JDK 后虽然能跑起来但日志里时不时出现Unable to make field accessible的警告这是反射访问内部字段被拦截的表现。短时间可以靠--add-opens压制但长期还是建议同步升级框架版本。如果你用了字节码增强类框架比如某些 APM 探针和 Mock 工具升级前务必要确认它们对 JDK 26 的支持。这类工具往往直接操作 JDK 内部类JDK 升级后很容易产生兼容问题。我们在测试环境就遇到过探针上报线程 CPU 占用飙高的情况降级探针版本后才恢复。4. 让升级不出乱子灰度发布、验证与回滚4.1 灰度发布设计升级动作本身其实不复杂复杂的是如何让风险可控。我们的发布策略是分四步走先上 1 个节点观察再按 5% 流量放量确认没问题后扩到 30%最后全量。每一步中间至少观察 2 到 4 个小时中间如果出现任何指标异常立即暂停放量并把该节点摘除。灰度期间的监控重点非常明确。第一个是接口响应时间特别是 P99 和 TP999 是否有尖刺第二个是 JVM GC 频率和耗时尤其是 Full GC 次数有没有从 0 变成非 0第三个是应用日志里是否出现异常堆栈比如 NoClassDefFoundError、IllegalAccessError 和 NoSuchMethodError最后还要盯 CPU 和内存使用率曲线防止新版本存在资源泄漏问题。为了让新旧版本能直接对比我们在网关层给灰度流量打上了染色标记全链路日志里都会带上这个标记。这样对比数据的时候可以直接按标记过滤不用猜哪些请求是走的新版本。如果你的网关不支持染色标记退一步可以通过单独的实例 ID 过滤日志效果也差不多只是麻烦一点。灰度过程中我们还做了一个所有实例大版本统一的操作在新版本实例启动完成后用jcmd抽查线程状态和堆内存分布确认虚拟线程调度正常、ZGC 内存池分配合理。这一步不需要每个实例都做但前 3 台实例一定要做能发现很多压测时不容易暴露的问题。4.2 单实例验证清单在灰度流量放进来之前我们会对新版本实例跑一轮比较全面的功能验证。验证不能只靠自动化测试很多低频功能必须靠手工点一遍。我整理了一份可以直接复用的单实例验证清单核心接口冒烟订单创建、查询、取消库存扣减与回滚定时任务执行确认任务正常触发并且没有重复执行消息队列消费上下游消息收发、重试和死信队列是否正常数据库读写分库分表路由、事务回滚、慢 SQL 日志分布式锁多个实例抢占锁时是否出现并发问题权限和导出后台导出 Excel、文件上传下载、权限校验长连接场景WebSocket 推送和心跳保活是否正常每个验证项都要记录结果和时间点出了问题和后面回滚时排查都方便。特别是定时任务和消息队列这两个最容易在新 JDK 上出问题因为线程模型变化会直接影响到调度器和消费线程的行为。我们还额外做了一次“升级后复测”的动作在新版本实例稳定运行 2 小时后重新跑了一遍压测脚本用压测结果和升级前数据对齐。这一步能确认性能提升是否真实存在避免出现“功能正常但性能倒退”的隐性回归。4.3 回滚策略与备份灰度做得再好也要给回滚留好后路。我们的回滚方案分两层第一层是网关切流把灰度实例从负载均衡里摘掉流量全部回到旧版本实例第二层才是物理回滚把部署目录切换回旧版本包。两层配合起来即使在最极端情况下也能在几分钟内恢复服务。回滚最容易忽略的是数据兼容。升级过程中如果数据库连接池配置变了、或者某个中间件连接属性改了回滚旧版本时会因为配置不匹配直接起不来。我们对所有配置变更都做了可逆处理数据库连接池参数单独用一份配置文件管理回滚时直接切换这份文件不需要发布新包。另外一个实操心得是旧版本的 JDK 安装目录不要急着删。我们在某台机器上回滚时发现启动脚本里引用的 JDK 路径已经被覆盖了只好临时重新解压一份白白浪费了几分钟。回滚方案里明确要求保留每台机器上的旧 JDK 目录至少保留一个发布周期。我们还在发布系统里加了一个一键回滚的入口整个操作流程固定为三个动作切换网关权重、替换启动脚本里的 JDK 路径、重启实例。演练过一次回滚流程耗时约 10 分钟效果还算满意。这里要强调回滚方案一定要演练不演练就是纸上谈兵真出事的时候手忙脚乱反而更容易出二次事故。最后再分享一个小技巧个人在整个升级过程中体会最深的一点是升级 JDK 最大的价值不一定是那一堆性能数据而是强制整个团队把 JVM、依赖、中间件这些平时不太关心但又至关重要的底层组件重新梳理了一遍。很多老代码里沉淀了几个版本都没人敢动的技术债在这次升级中被迫清理掉了这种收益比单纯的性能提升更值钱。如果你接下来也要做类似升级我的建议是先把jdeps扫描和第三方依赖适配这两件事做扎实然后再去聊性能优化。兼容性没有解决之前性能数据做得再漂亮也没意义。操作上记得多做灰度对比、多保留旧版本永远给自己留一条安全后退的路。
阅读完成 · 觉得有帮助？
