JVM垃圾回收器：CMS与G1原理及调优实战

1. 垃圾回收器深度解析：从CMS到G1的演进之路

在JVM性能调优领域，垃圾回收器（Garbage Collector）的选择直接影响着应用的吞吐量和延迟表现。上篇我们探讨了基础回收算法和Serial/Parallel回收器，这次将深入分析两款生产环境常用的高级回收器：CMS（Concurrent Mark-Sweep）和G1（Garbage-First）。作为在电商大促场景中处理过多次GC问题的老兵，我将分享这两款回收器的实战配置经验和避坑指南。

2. CMS回收器详解

2.1 并发标记清除原理

CMS采用"标记-清除"算法实现，其最大特点是实现了垃圾回收线程与用户线程的并发执行。整个回收过程分为四个阶段：

1. 初始标记（STW）：标记GC Roots直接关联的对象，耗时极短
2. 并发标记：遍历对象图进行可达性分析
3. 重新标记（STW）：修正并发标记期间变动的引用关系
4. 并发清除：清理不可达对象

这种设计使得老年代回收的停顿时间大幅缩短，特别适合4-8GB堆内存、追求低延迟的Web服务。我在某金融支付系统中采用CMS后，将老年代GC停顿从1.2秒降至200毫秒以内。

2.2 关键参数配置

bash复制-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=75 
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+CMSScavengeBeforeRemark

重要提示：CMSInitiatingOccupancyFraction不宜超过80，否则容易引发并发模式失败（Concurrent Mode Failure），导致退化为Serial Old收集器。

2.3 典型问题排查

场景1：晋升失败（Promotion Failed）
日志特征：

code复制[GC (Allocation Failure) [ParNew: 3145728K->349696K...]

解决方案：

• 增加-XX:SurvivorRatio（默认8）降低存活对象晋升速度
• 添加-XX:+UseCMSCompactAtFullCollection减少碎片

场景2：并发模式失败
监控指标：

• CMS_FINAL_REMARK耗时突增
• 出现"Concurrent Mode Failure"日志

优化方向：

• 降低CMSInitiatingOccupancyFraction（建议65-75）
• 增加-XX:ConcGCThreads数量（建议=CPU核数/4）

3. G1回收器深度剖析

3.1 区域化内存布局

G1将堆划分为2048个大小相等的Region（默认值），每个Region可能是Eden、Survivor或Old区。这种设计带来两个核心优势：

1. 可预测的停顿模型：通过-XX:MaxGCPauseMillis（默认200ms）设定目标停顿时间
2. 混合回收策略：优先回收垃圾比例高的Region（Garbage-First原则）

实测在16GB堆内存的订单系统中，G1相比CMS将最差停顿时间从800ms稳定到250ms以内。

3.2 核心工作流程

1. 年轻代回收（Young GC）：并行STW回收Eden/Survivor区
2. 并发标记周期：
   • 初始标记（STW）
   • 根区域扫描
   • 并发标记
   • 最终标记（STW）
   • 清理（STW）
3. 混合回收（Mixed GC）：同时回收年轻代和老年代Region

3.3 关键调优参数

bash复制-XX:+UseG1GC
-XX:MaxGCPauseMillis=200 
-XX:InitiatingHeapOccupancyPercent=45
-XX:G1ReservePercent=10

经验之谈：G1ReservePercent建议保持10-15%，用于应对晋升失败情况。某次大促期间因忽略该参数导致连续Full GC。

4. CMS与G1的抉择指南

4.1 选择决策树

mermaid复制graph TD
    A[堆大小<6GB?] -->|是| B[要求亚秒级停顿?]
    A -->|否| C[考虑G1]
    B -->|是| D[使用CMS]
    B -->|否| E[Parallel Old]

4.2 性能对比实测

在某用户中心服务（8GB堆）的压测数据：

5. 高级调优技巧

5.1 日志分析实战

使用GCViewer分析日志时重点关注：

1. Throughput曲线是否平稳
2. Pause Time分布是否满足SLA
3. Heap After GC趋势线是否持续上升

5.2 内存泄漏排查

当发现老年代持续增长时：

1. 添加-XX:+HeapDumpBeforeFullGC
2. 使用MAT分析支配树（Dominator Tree）
3. 检查大对象分配（-XX:G1HeapRegionSize）

5.3 容器化部署要点

在K8s环境中需特别注意：

yaml复制resources:
  limits:
    memory: "8192Mi"
  requests:
    memory: "8192Mi"

容器内存必须等于JVM最大堆内存，否则容易引发OOM Killer误杀。去年某次线上事故就源于此配置缺失。

6. 未来演进方向

ZGC和Shenandoah作为新一代回收器，已在JDK15+版本实现亚毫秒级停顿。但在JDK11 LTS环境下，G1仍是大多数场景的最优解。建议在测试环境先用-XX:+UnlockExperimentalVMOptions -XX:+UseZGC进行验证。

通过合理选择回收器+精准参数调优，我们成功将某风控系统的GC停顿控制在100ms内。记住没有银弹，只有最适合业务场景的解决方案。当遇到GC问题时，建议按照"日志分析->参数调整->架构优化"的步骤循序渐进。