从CMS到ZGC：我的Java应用GC升级实战与踩坑记录（附JDK 23分代模式配置）

去年双十一大促前，我们的支付网关突然出现了几次长达2秒的响应延迟。通过APM工具追踪，发现问题出在G1垃圾收集器的Full GC阶段——堆内存达到48GB时，STW停顿直接击穿了SLA的200ms红线。作为技术负责人，我决定对系统GC策略进行彻底改造。本文将分享从传统收集器迁移到ZGC的全过程，特别是JDK 23分代模式的实际调优经验。

1. 为什么选择ZGC？

在评估阶段，我们对比了三种主流收集器的关键指标：

指标	CMS	G1	ZGC
最大堆支持	8-16GB	百GB级	16TB
停顿时间	100ms-数秒	10-200ms	<1ms-10ms
分代支持	是	是	JDK23+支持
内存开销	低	中等	较高
适用场景	中小堆传统应用	大堆平衡型应用	超大堆低延迟场景

关键发现 ：当堆内存超过32GB时，ZGC的停顿时间仍能保持在10ms以下，而G1的停顿会随堆大小线性增长。我们的支付网关具有两个典型特征：

• 日均交易量超过3000万笔，要求99.99%响应时间≤100ms
• 本地缓存+事务上下文导致堆内存需求达40-50GB

这正好命中ZGC的设计目标。但需要注意两个前提条件：

1. 必须使用Linux内核4.11+（支持多映射内存）
2. 建议物理内存≥1.5倍堆大小

2. 升级前的关键准备

2.1 环境验证与基准测试

在预发布环境搭建对比测试平台：

# 测试环境配置
OS: CentOS 7.9 (kernel 5.4)
CPU: 32核 Intel Xeon
MEM: 96GB
JDK: 
  - 对照组: jdk8u372 (G1)
  - 实验组: jdk23-ea (ZGC)

使用JMeter模拟三种典型负载：

1. 稳态流量 ：5000 TPS持续压力
2. 峰值冲击 ：0→8000 TPS瞬时爆发
3. 内存泄漏 ：注入5%无法回收的对象

测试结果令人惊喜：

• 99.9%延迟从G1的143ms降至ZGC的21ms
• GC停顿时间从186ms降至2.3ms
• 吞吐量损失仅3.7%（从4820→4642 TPS）

但同时也暴露一个问题：RSS内存显示为78GB，远超实际堆使用量。这是由于Linux统计多映射内存的已知问题，可通过添加大页配置缓解：

# 调整内核参数
echo "vm.nr_hugepages = 1024" >> /etc/sysctl.conf
sysctl -p

2.2 JDK版本选择：21 vs 23

我们重点对比了两个LTS版本的ZGC实现：

特性	JDK21 ZGC	JDK23 ZGC
默认模式	非分代	分代式（推荐）
最大堆内存	16TB	16TB
年轻代回收	全堆扫描	独立分代收集
内存占用	较高	降低20-30%
参数复杂度	简单	新增分代调优参数

最终选择JDK23的三个理由：

1. 分代模式对短生命周期对象处理更高效
2. 默认-XX:+ZGenerational减少配置成本
3. 官方承诺后续优化都集中在分代实现

3. 分代ZGC实战配置

3.1 基础参数模板

支付网关的最终配置：

# 基础内存设置
-Xmx48g -Xms48g 
-XX:ZYoungGenerationSize=4g  # 年轻代初始大小
-XX:ZYoungGenerationMaxSize=8g # 年轻代弹性上限

# GC策略选择
-XX:+UseZGC                  # 启用ZGC（JDK23默认分代）
-XX:-ZProactive              # 关闭主动回收（避免频繁GC）

# 线程调优
-XX:ConcGCThreads=6          # 并发GC线程数（核数×0.25）
-XX:ParallelGCThreads=12     # 并行GC线程数（核数×0.5）

# 监控日志
-Xlog:gc*=info:file=/logs/gc_%t.log:time,level,tags:filecount=10,filesize=100m

关键参数解析 ：

• ZYoungGenerationSize ：建议设为堆大小的10-15%，过小会导致晋升频繁
• ConcGCThreads ：并发阶段线程数，建议不超过物理核数的1/4
• -ZProactive ：在流量平稳时开启更好，但突发流量场景可能引发意外GC

3.2 分代模式特有优化

通过GC日志发现年轻代回收频率过高（约30秒一次），调整策略：

- -XX:ZYoungGenerationSize=4g
+ -XX:ZYoungGenerationSize=6g
+ -XX:ZAllocationSpikeTolerance=3.0 # 提高触发阈值

优化后效果：

• 年轻代GC间隔延长至90-120秒
• 单次回收时间从40ms降至28ms
• 老年代晋升率从15%降至9%

4. 生产环境踩坑记录

4.1 mmap上限问题

上线首日出现 OutOfMemoryError: Map failed 错误，经排查是系统内存映射数不足：

# 查看当前配置
cat /proc/sys/vm/max_map_count # 默认65536

# 计算需求值（48G堆，2M的ZPage）
echo $(( (48*1024/2)*3*1.2 )) # 需要41472映射数

# 永久生效配置
echo "vm.max_map_count=131072" >> /etc/sysctl.conf
sysctl -p

4.2 RSS内存膨胀

监控系统报警显示进程占用72GB内存，但实际堆使用仅38GB。这是ZGC在Linux小页模式下的统计问题，解决方案：

1. 改用透明大页（推荐）：

   echo "always" > /sys/kernel/mm/transparent_hugepage/enabled
   

2. 或者直接配置大页：

   # 计算需要的大页数量（假设2MB页）
   pages=$(( (48*1024)/2 ))
   echo "vm.nr_hugepages=$pages" >> /etc/sysctl.conf
   

4.3 冷启动性能问题

系统重启后出现短暂性能下降，通过预热解决：

// 启动时主动触发初始GC
public class Warmup {
    public static void main(String[] args) {
        System.gc(); // 触发初始标记
        // 模拟业务流量分配对象
        for(int i=0; i<1000000; i++){
            new CacheEntry().putInCache();
        }
    }
}

5. 性能对比与收益

上线一个月后的关键指标变化：

指标	G1时期	ZGC时期	提升幅度
平均GC停顿	186ms	2.1ms	98.9%↓
P99延迟	143ms	28ms	80.4%↓
最大吞吐量	5200 TPS	5400 TPS	3.8%↑
故障恢复时间	45秒	8秒	82.2%↓

特别在秒杀场景下，ZGC的表现远超预期：当瞬时流量从5000激增到15000 TPS时，G1会出现长达1.5秒的停顿，而ZGC的停顿曲线依然平稳：

![GC停顿时间对比图]

经验总结 ：对于50GB左右堆内存的高并发服务，ZGC分代模式能带来质的飞跃。但要注意：

• 预留足够物理内存（建议堆大小×1.5）
• 合理设置年轻代大小避免频繁回收
• 生产环境务必配置GC日志监控