CMS 垃圾收集器

CMS (Concurrent Mark Sweep) 垃圾收集器是 Java 历史上里程碑式的收集器，它以“获取最短回收停顿时间”为目标，首次实现了垃圾收集线程与用户线程并发执行。

虽然 CMS 已在 JDK 14 中被废弃，并在 JDK 15 中彻底移除（被 ZGC 和 G1 取代），但理解其底层原理对于深入掌握 JVM 内存管理、理解 GC 演进历史以及维护老旧系统（JDK 8/11）仍然至关重要。

---

🧠 核心设计理念

• 目标：最小化 Stop-The-World (STW) 时间，提升用户体验（低延迟）。
• 算法：标记 - 清除 (Mark-Sweep)。
  • 注意：它不是“标记 - 整理”，因此会产生内存碎片。
• 并发：在“标记”和“清除”阶段，GC 线程与用户线程同时运行。

---

⚙️ CMS 垃圾回收的四个阶段

CMS 的回收过程分为 4 个主要步骤，其中第 2 步和第 4 步是并发的（与用户线程一起跑），第 1 步和第 3 步需要暂停用户线程（STW）。

1. 初始标记 (Initial Mark) —— [STW]

• 动作：GC 暂停所有用户线程，快速标记出直接从 GC Roots 可达的对象。
• 特点：
  • 速度极快（只扫描根节点直接关联的对象，不遍历整个对象图）。
  • 必须 STW，因为需要保证根节点的准确性。
• 耗时：通常很短，取决于 Root 集合的大小。

2. 并发标记 (Concurrent Mark) —— [并发]

• 动作：GC 线程从初始标记的对象出发，并发地遍历整个对象图，标记所有可达对象。
• 特点：
  • 用户线程继续运行，GC 线程在后台慢慢标记。
  • 关键问题：在此期间，用户线程可能会修改对象的引用关系（例如：A 指向 B，用户线程把 A 的引用断了，或者让 C 指向了 D）。
  • 解决方案：使用 增量更新 (Incremental Update) 或 写屏障 (Write Barrier) 技术记录这些变化（稍后在“重新标记”阶段处理）。

3. 重新标记 (Remark) —— [STW]

• 动作：再次暂停用户线程，修正并发标记期间因用户程序运作而导致标记产生变动的那一部分记录的标记。
• 为什么需要？
  • 因为在“并发标记”阶段，用户线程在跑，对象引用关系可能变了。如果不重新检查，可能会漏掉某些存活对象，导致错误回收。
• 特点：
  • STW 时间比“初始标记”长，但远小于“并发标记”的时间。
  • 它是 CMS 性能调优的关键点（如果这一步太长，说明并发期间对象变动太剧烈）。

4. 并发清除 (Concurrent Sweep) —— [并发]

• 动作：GC 线程并发地清除那些未被标记的对象（即垃圾），释放内存。
• 特点：
  • 用户线程继续运行。
  • 副作用：由于是并发清除，清除过程中用户线程可能还在产生新垃圾（浮动垃圾），这些垃圾只能等到下一次 GC 再清理。
  • 碎片问题：因为是“标记 - 清除”，清理后内存空间是不连续的。

---

⚠️ CMS 的三大致命缺陷

CMS 虽然降低了停顿时间，但付出了其他代价，这也是它最终被移除的原因：

1. 内存碎片化 (Memory Fragmentation)

• 原因：CMS 采用标记 - 清除算法，回收后不会整理内存（不像 Serial Old 或 G1/ZGC 的整理机制）。
• 后果：
  • 长期运行后，堆内存中会留下大量不连续的小空闲块。
  • 当需要分配大对象时，即使总剩余内存足够，也可能因为找不到连续的内存块而触发 Full GC。
  • Full GC 时会启用 Serial Old 收集器进行“标记 - 整理”，导致长时间的 STW（这是 CMS 最糟糕的时刻）。
• 缓解：-XX:+UseCMSCompactAtFullCollection (Full GC 后整理)，但整理过程是 STW 的。

2. 浮动垃圾 (Floating Garbage)

• 原因：在“并发清除”阶段，用户线程仍在运行并产生新对象，同时旧对象也可能变成垃圾。这些新产生的垃圾无法在当前周期被清除。
• 后果：
  • CMS 不能像其他收集器那样等待堆完全满了再回收，必须预留一部分空间给用户线程使用。
  • 触发阈值通常设为 -XX:CMSInitiatingOccupancyFraction (默认 68%，即老年代用到 68% 就开始 GC)。
  • 如果预留空间不够，或者浮动垃圾太多，会导致 Concurrent Mode Failure，进而触发 Full GC。

3. 对 CPU 资源敏感

• 原因：并发阶段（标记和清除）需要 GC 线程与用户线程争夺 CPU 时间片。
• 后果：
  • 为了保证用户线程的性能，CMS 会限制 GC 线程的数量（默认 (CPU 核数 + 3) / 4）。
  • 在 CPU 负载已经很高的情况下，开启 CMS 会导致用户线程变慢，整体吞吐量下降。

---

📊 CMS vs. G1 vs. ZGC (原理对比)

特性	CMS	G1	ZGC
算法基础	标记 - 清除	分区 (Region) + 标记 - 整理	染色指针 + 读屏障 + 并发整理
内存整理	❌ 不整理 (有碎片)	✅ 自动整理 (无碎片)	✅ 自动整理 (无碎片)
并发程度	标记、清除并发	标记、转移、整理并发	几乎所有阶段并发
停顿时间	较低 (但在 Full GC 时极高)	可控 (可预测)	极低 (<1ms, 恒定)
主要痛点	碎片、浮动垃圾、CPU 敏感	CPU 占用略高，大堆下 Region 管理开销	实现复杂，早期版本成熟度低
现状	已移除	默认首选	高性能首选

---

🛠️ 经典调优参数 (针对仍在使用 JDK 8 的场景)

如果你还在维护基于 JDK 8 的 CMS 系统，以下参数至关重要：

1. 触发阈值：

   -XX:CMSInitiatingOccupancyFraction=75
   

   • 设置老年代使用率达到 75% 时启动 CMS GC。默认是 68%，调高可以减少 GC 频率，但增加了 Concurrent Mode Failure 的风险。

2. Full GC 后压缩：

   -XX:+UseCMSCompactAtFullCollection
   -XX:CMSFullGCsBeforeCompaction=0
   

   • 每次 Full GC 后都进行内存整理，解决碎片问题（但这会增加 Full GC 的停顿时间）。

3. 并发线程数：

   -XX:ParallelCMSThreads=4
   

   • 手动指定并发阶段的线程数，避免在多核机器上线程过少导致 GC 太慢。

4. 处理失败策略：

   -XX:+CMSClassUnloadingEnabled
   

   • 允许 CMS 卸载不再使用的类（减少 Metaspace 压力）。

---

💡 总结与启示

CMS 的历史使命已经完成。

• 它证明了并发 GC的可行性，教育了业界“低延迟”的重要性。
• 它的碎片化问题直接催生了 G1 的“分区整理”设计。
• 它的停顿时间瓶颈推动了 ZGC “读屏障”和“染色指针”技术的诞生。

建议：

• 如果是 JDK 8 老项目：尽量优化参数，监控 Concurrent Mode Failure 和 Full GC 频率。如果频繁 Full GC，考虑升级堆内存或迁移到 G1 (-XX:+UseG1GC)。
• 如果是 JDK 11+：绝对不要尝试找回 CMS（已移除）。直接使用 G1（通用）或 ZGC（超低延迟）。