提升JVM性能之CMS垃圾回收器的优化分析与案例剖析

优化CMS垃圾回收器（Concurrent Mark-Sweep）是提升JVM性能的关键手段，尤其适用于追求低延迟的老年代回收场景。以下结合核心优化策略与真实案例，为你提供系统化的解决方案：

一、CMS基本介绍

核心目标： CMS 垃圾回收器的主要设计目标是 最小化垃圾回收导致的应用程序停顿时间（Stop-The-World, STW）。它特别适用于那些对响应时间敏感的应用程序，例如 Web 服务器、GUI 桌面应用、API 服务等。

核心特点： 并发标记和清除

CMS 的核心在于它的大部分工作（标记和清除阶段）是与用户线程并发执行的，大大减少了 STW 的时间。这也是它被称为“并发”收集器的原因。

工作流程（四个主要阶段）：

1. 初始标记（Initial Mark - STW）：

   • 这是第一个短暂的 STW 阶段。
   • 目标：快速标记所有直接从 GC Roots（如线程栈变量、静态变量、JNI 引用等）直接可达的存活对象。
   • 为什么快？因为它只标记直接关联的对象，不进行深度扫描。
   • 停顿时间通常很短。

2. 并发标记（Concurrent Mark）：

   • 最重要的并发阶段。
   • 目标：沿着初始标记阶段标记出的存活对象图，深度遍历整个老年代对象图，标记所有可达的（存活的）对象。
   • 关键点： 这个阶段与用户线程并发执行。用户线程仍在运行，可能会修改对象的引用关系（导致新对象产生或旧对象不可达）。
   • 因为并发，此阶段耗时较长，但不会暂停应用。

3. 重新标记（Remark - STW）：

   • 第二个（通常也是较长的）STW 阶段。
   • 目标：修正在并发标记阶段，由于用户线程继续运行而导致发生变化的引用关系（即标记那些在并发标记过程中新产生的垃圾或新晋升为存活的对象）。CMS 使用了一些技术（如增量更新或原始快照）来高效地完成这个修正工作。
   • 虽然需要 STW，但 CMS 通过各种优化手段（如预清理、卡表）尽量缩短这个阶段的时间。
   • 停顿时间比初始标记长，但远小于并发标记的总时间（因为并发标记不暂停）。

4. 并发清除（Concurrent Sweep）：

   • 第三个并发阶段。
   • 目标：回收在标记阶段被确定为不可达（垃圾）的对象所占用的内存空间。
   • 关键点： 这个阶段与用户线程并发执行。用户线程可以继续分配新对象。
   • 回收后的内存空间不会立即进行压缩整理，因此是空闲列表（Free List）管理。

关键优势和适用场景：

• 低延迟/短停顿： 最大的优势！通过并发执行大部分耗时的标记和清除工作，显著减少了 STW 的总时间，使得应用程序响应更流畅。
• 适合交互式应用： 对用户交互响应时间要求高的场景（如 GUI 程序、Web 请求响应）。
• 老年代收集器： CMS 主要用来回收老年代的对象。它通常需要与一个负责新生代回收的收集器（最常见的是 ParNew）配合使用。

主要缺点和挑战：

1. CPU 资源敏感：

   • 在并发标记和并发清除阶段，垃圾回收线程会与用户线程竞争 CPU 资源。如果 CPU 资源紧张，可能导致应用程序吞吐量下降。
   • 默认的回收线程数 = (CPU 核心数 + 3)/4。在 CPU 核心数少的情况下，并发回收线程可能占用过多 CPU。

2. 无法处理“浮动垃圾”（Floating Garbage）：

   • 在并发标记阶段，用户线程还在运行，可能产生新的垃圾对象（标记阶段结束后才成为垃圾）或使一些已标记的对象变为垃圾。
   • 这些垃圾（浮动垃圾）无法在当前回收周期被清除，只能留到下一次 GC。
   • 这可能导致需要预留更多空间（-XX:CMSInitiatingOccupancyFraction 参数设置触发阈值，如 70%），以防在回收完成前老年代就满了。

3. “并发模式失败”（Concurrent Mode Failure）：

   • 最严重的问题！ 如果在 CMS 执行过程中（特别是并发阶段），老年代空间不足以容纳从新生代晋升上来的对象或者新分配的大对象，JVM 就会被迫中断 CMS 的并发回收过程。
   • 此时，JVM 会触发一次 Serial Old（单线程）Full GC。这是一个非常耗时的 STW 过程，会暂停所有用户线程，并对整个堆（包括新生代和老年代）进行标记-清除-压缩。这与使用 CMS 的初衷（低延迟）背道而驰。
   • 触发原因通常是：老年代空间预留不足（触发阈值设置过高）、晋升过快、大对象过多、内存碎片严重导致无法分配连续空间。

4. 内存碎片（Memory Fragmentation）：

   • CMS 采用的是 标记-清除（Mark-Sweep）算法，而不是标记-整理（Mark-Compact）。它只清除垃圾对象，不移动存活对象进行内存压缩。
   • 经过多次回收后，老年代会产生大量不连续的内存碎片。当需要分配一个较大连续内存空间的对象时，即使总的剩余空间足够，也可能因为找不到足够大的连续空间而触发 Full GC（通常是 Serial Old） 来进行压缩整理。
   • 为了缓解碎片，CMS 提供了 -XX:+UseCMSCompactAtFullCollection（在 Full GC 时压缩，默认开启）和 -XX:CMSFullGCsBeforeCompaction（执行多少次不压缩的 Full GC 后，再执行一次带压缩的 Full GC，默认为 0，表示每次进入 Full GC 都压缩）参数，但这又会带来更长的 STW 时间。

5. 对新生代回收器的依赖： CMS 本身不管理新生代，必须配合一个新生代收集器（如 ParNew、Serial）。如果新生代 GC 频繁或耗时长，也会间接影响整体停顿时间。

二、CMS核心优化策略

1. 避免并发模式失败（Concurrent Mode Failure）

• 问题本质：CMS并发清理时，老年代空间不足以容纳新晋升对象，触发Full GC（Stop-The-World）。
• 优化方案：
  • 增大老年代空间（-XX:NewRatio 调整新生代/老年代比例）
  • 降低对象晋升速度：

    -XX:MaxTenuringThreshold=6      # 提高对象在新生代存活次数
    -XX:+UseCMSInitiatingOccupancyOnly
    -XX:CMSInitiatingOccupancyFraction=70  # 老年代70%时启动CMS
    

2. 减少内存碎片

• 启用压缩：

  -XX:+UseCMSCompactAtFullCollection   # Full GC后压缩内存
  -XX:CMSFullGCsBeforeCompaction=2     # 每2次Full GC压缩一次
  

3. 调优并发阶段耗时

• 缩短初始标记（STW阶段）：

  -XX:+CMSParallelInitialMarkEnabled  # 并行初始标记
  

• 并发标记/清理线程数：

  -XX:ConcGCThreads=4  # 推荐为CPU核数的1/4
  

4. 新生代优化配合

• 选择合适的新生代回收器：

  -XX:+UseParNewGC  # CMS默认搭配ParNew
  

• 调整Eden/Survivor：

  -XX:SurvivorRatio=8  # Eden与Survivor比例
  

三、典型案例解析

案例1：电商服务频繁Full GC

• 现象：高峰期每10分钟发生Concurrent Mode Failure，停顿2秒。
• 原因分析：
  • 老年代大小固定为2GB，CMSInitiatingOccupancyFraction=68
  • 日志显示并发阶段未完成时老年代已满
• 优化措施：

  -XX:CMSInitiatingOccupancyFraction=60  # 更早启动CMS
  -XX:NewRatio=3                         # 老年代从2GB→3GB
  -XX:MaxTenuringThreshold=8             # 减少短期对象晋升
  

• 结果：Full GC消失，平均延迟下降65%

案例2：金融交易系统碎片导致长时间停顿

• 现象：每日凌晨Full GC耗时8秒，影响结算流程。
• 原因分析：
  • CMSFullGCsBeforeCompaction=0（默认每次Full GC都压缩）
  • 内存碎片率达40%
• 优化措施：

  -XX:CMSFullGCsBeforeCompaction=4     # 减少压缩频率
  -XX:+UseCMSInitiatingOccupancyOnly
  -XX:CMSInitiatingOccupancyFraction=50 # 预留更多空间防失败
  

• 结果：Full GC时间降至1.5秒，碎片率<15%

四、关键参数清单

五、升级替代方案

若优化后仍不满足需求（如堆>8GB或停顿>200ms），考虑迁移至：

1. G1垃圾回收器：

   -XX:+UseG1GC -XX:MaxGCPauseMillis=200
   

2. ZGC（JDK11+）：

   -XX:+UseZGC -Xmx16g  # 亚毫秒级停顿
   

六、调优流程

1. 监控诊断：

   -Xlog:gc*:file=gc.log  # JDK9+统一日志
   jstat -gcutil <pid> 1000
   

2. 分析工具：
   • GCViewer 分析日志
   • Eclipse Memory Analyzer 排查内存泄露
3. 压测验证：

   jmeter -n -t test.jmx # 模拟流量验证优化效果
   

关键建议：CMS优化需结合对象生命周期分析（JProfiler）与压力测试，避免仅凭经验调整。对于新项目，优先选择G1或ZGC以规避CMS碎片问题。