Java 后端 2026 演进（二）：JDK 21/25 升级实战与 GC 选型——架构师决策手册

Java 后端 2026 演进（二）：JDK 21/25 升级实战与 GC 选型——架构师决策手册

系列定位：Java 后端演进主线 · 第 2 篇 · 面向架构师选型视角
读者：负责 JDK 升级治理、GC 调优与稳定性保障的技术负责人 / 架构师
接上篇：A1《虚拟线程落地——架构师并发模型选型与 ROI》

0. 为什么这是架构师必答题

很多团队把"升级 JDK"当成开发的事，实际上它有三重架构含义：

1. 生命周期风险：Java 8 早已停止免费公共更新，Java 11 的免费支持窗口也在收紧。停在老 JDK 等于停在无人修安全补丁的版本上。
2. 能力解锁：虚拟线程（JDK 21）、紧凑对象头与 ScopedValue（JDK 25）这些"免费午餐"只有升上去才吃得到——升 JDK 不是版本替换，是运行时能力的系统升级。
3. GC 决策：GC 默认配置直接决定 P99。选错收集器，再好的业务代码也救不了长尾延迟。

本篇给你两张可直接下发的决策表（JDK 版本选型、GC 选型）和一份升级踩坑清单。

1. JDK LTS 路线图与版本选型

Oracle 自 JDK 21 起把 LTS 节奏固定为 每两年一个：17（2021）→ 21（2023）→ 25（2025，当前最新 LTS） → 29（2027）。

架构师口径：

• 新项目直接 JDK 21（生态最成熟、虚拟线程 GA、风险最低）。
• 对延迟 / 内存极度敏感、且依赖库已适配 JDK 25 的服务，可上 25 吃紧凑对象头（堆省 ~22%）与 ScopedValue 红利。
• 存量系统分批升 17 → 21，不要在没验证依赖兼容前跳 25。

2. 升级踩坑清单（上线前必须过一遍）

Maven 指定 JDK 25 编译：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.13.0</version>
  <configuration>
    <release>25</release>
  </configuration>
</plugin>

Gradle Toolchain：

java { toolchain { languageVersion = JavaLanguageVersion.of(25) } }

3. GC 选型决策表（2026 现实状态）

关键事实：JDK 25 通过 JEP 523 让 G1 成为所有环境的默认 GC（包括此前回退到 Serial 的受限环境）。分代 ZGC 自 JDK 23 起为默认 ZGC 模式、JDK 24 移除非分代模式，JDK 25 是首个承载该最终形态的 LTS；分代 Shenandoah 在 JDK 25 转正、不再需要实验开关。

快速决策树（架构师可直接用）：

1. 有没有人同步等待这个应用的响应？→ 没有（批处理/数据管道）→ Parallel GC，吞吐最高。
2. 有同步等待，且 P99/P999 SLA < 10ms 或 堆 > 32GB？→ 远离 G1，选 ZGC 或 Shenandoah。
3. 其他通用服务端 → G1（JDK 25 默认，对大多数负载足够好，别盲目换）。

4. ZGC 深度：为什么它能把停顿压到亚毫秒

ZGC 的核心思路：几乎所有工作并发做，包括对象移动。它的 STW 停顿只与 GC 根（线程栈、静态字段）数量成正比，不随堆大小增长——所以 2GB 和 2TB 堆的停顿都在几十微秒级。

机制一句话：着色指针（Colored Pointers）+ 读屏障（Load Barrier）。64 位指针的高位 spare bits 被用作元数据（对象是否已标记/已搬迁），引用访问时由读屏障透明处理对象 relocation，应用线程全程不冻结。

实测对照（JDK 25.0.3，公开基准，典型量级）：

代价：读屏障带来少量吞吐损耗（通常中个位数百分比），且大堆下禁用压缩普通对象指针（compressed oops）会增加内存占用。低延迟场景这代价完全值得。

最小开启（JDK 25 已默认启用 ZGC 2.0 全部增强）：

java -XX:+UseZGC -Xmx16g -jar app.jar

5. Shenandoah vs ZGC：怎么二选一

两者都是低延迟、大堆友好，差异在工程实现与生态：

• ZGC：着色指针实现，停顿最低（亚毫秒），JDK 内置、无需额外依赖，分代模式已成默认形态。
• Shenandoah：Brooks 指针 / 转发指针实现，停顿 <10ms，在超大堆与特定内存布局下表现均衡；JDK 25 转正后可用性大幅提升。

选型经验：优先 ZGC（停顿更低、实现更"原生"）；若所用发行版/场景对 Shenandoah 有特定优化或团队更熟，Shenandoah 是等价备选。两者都不该在"通用小服务"上浪费。

6. 被遗忘的正确答案：Parallel GC

多数讨论只比 G1/ZGC/Shenandoah，却忘了 Parallel GC——吞吐量优先的原始收集器，至今扛着大量批处理 / ETL 负载。只要没有人在同步等响应，Parallel GC 的吞吐最高、调参最少。架构师的正确动作是：别给离线任务配低延迟 GC，Parallel 才是它的归宿。

7. JVM 参数示例（可直接套用）

低延迟服务（ZGC + 容器显式堆 + GC 日志）：

java -XX:+UseZGC \
     -Xms4g -Xmx8g \
     -XX:+AlwaysPreTouch \
     -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=100M \
     -jar app.jar

通用服务端（G1，JDK 25 默认，仅显式堆与日志）：

java -Xms2g -Xmx4g \
     -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=100M \
     -jar app.jar

JDK 25 默认按系统 RAM 的 25% 分配堆，容器里务必显式 -Xmx，避免被宿主机内存误导。

8. ROI 量化（典型量级）

9. 迁移与灰度路径

1. 先评依赖：扫描 javax 引用、内部 API 使用、库版本兼容性（见第 2 节清单）。
2. CI 双版本编译：在 JDK 17/21 与 25 各跑一次构建与测试，捕获不兼容。
3. GC 灰度：先在非核心服务用 -XX:+UseZGC 小流量验证，对比 G1 的 P99 与吞吐。
4. 监控补齐：GC 日志 + 停顿时间 + 堆/晋升速率看板；ZGC 关注"Allocation Stall"次数（屏障压力信号）。
5. 回退开关：保留 G1 启动参数，异常时一键切回。

10. 风险与回退

• 风险 1：ZGC 吞吐损耗超预期。用真实业务流量做 A/B，吞吐掉太多则退回 G1 或评估 Shenandoah。
• 风险 2：大堆下 compressed oops 禁用致内存上涨。压测验证常驻内存，必要时调小堆或加机器。
• 风险 3：升级引入行为差异（如强封装导致老库失败）。灰度中保留旧 JDK 实例，快速回滚。
• 回退：GC 改 -XX:+UseG1GC 即回；JDK 版本回退靠构建产物与镜像标签，业务代码若已用 JDK 21 新 API 则不可降级。

11. 小结 & 下篇预告

JDK 升级是"运行时能力升级"而非版本替换：升到 21/25 顺手解锁虚拟线程、紧凑对象头、ScopedValue。GC 不要"默认就完事"——通用服务端用 G1，低延迟/大堆上 ZGC，批处理用 Parallel，每张表都能直接作为选型依据下发。

下一篇（A3）：《GraalVM 原生镜像与 AOT》——把 Spring Boot 应用压进 50MB、启动 <50ms，吃透 Serverless 冷启动解法与构建约束。

本篇为「Java 后端 2026 演进」系列第 2 篇。A1 虚拟线程 → A2 JDK/GC（本篇） → A3 GraalVM 原生镜像 → A4 Spring Boot 4 迁移；后续接入 B 线（AI 工程化）、C 线（云原生治理）、D 线（融合蓝图）。