JVM 垃圾回收时产生的 concurrent mode failure 的原因是什么？

JVM 垃圾回收时产生的 concurrent mode failure 的原因是什么？

在 JVM 中，concurrent mode failure 是垃圾回收器（通常是 CMS，即 Concurrent Mark-Sweep GC）在执行并发垃圾回收时，因老年代空间不足导致的失败。这种失败会迫使 JVM 采用 Stop-The-World（STW） 的方式，执行一次单线程的 Full GC，从而导致性能下降。

---

1. 什么是 CMS 回收器？

CMS（Concurrent Mark-Sweep） 是一种面向低延迟的垃圾回收器，主要针对老年代。它的目标是尽量减少垃圾回收的停顿时间，因此它以并发的方式与应用线程共同工作。

CMS 的回收过程：

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

   • 标记 GC Roots 直接引用的对象。
   • 停顿时间较短。

2. Concurrent Mark（并发标记）：

   • 在应用线程运行的同时，标记从 GC Roots 可达的对象。

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

   • 修正并发标记阶段因应用线程的运行而遗漏的标记。
   • 停顿时间较短。

4. Concurrent Sweep（并发清理）：

   • 在应用线程运行的同时，清理不可达的对象，释放内存。

---

2. concurrent mode failure 的原因

concurrent mode failure 的核心原因是 老年代内存不足，导致 CMS 无法完成垃圾回收。以下是具体场景：

原因 1：回收不及时

• CMS 的垃圾回收是并发的，但如果垃圾回收速度赶不上对象分配速度，老年代内存可能被快速填满，导致失败。

原因 2：碎片化问题

• CMS 是一种基于标记-清除的算法，不会进行内存压缩。因此，老年代可能存在大量碎片化的内存空间，导致大对象分配失败，即使总可用内存足够。

原因 3：晋升对象过多

• 如果新生代的垃圾回收过程中需要将大量存活对象晋升到老年代，而老年代空间不足，则会触发 concurrent mode failure。

原因 4：配置不合理

• CMS 的启动时机（由 -XX:CMSInitiatingOccupancyFraction 控制）过晚，导致老年代几乎填满时才开始回收，难以完成垃圾回收任务。

---

3. 如何解决 concurrent mode failure？

方法 1：调高 CMS 的启动阈值

• 通过参数 -XX:CMSInitiatingOccupancyFraction=<N> 配置 CMS 的启动阈值（默认是 68%，即老年代使用 68% 时启动垃圾回收）。
• 建议将值调低，例如设置为 50，使垃圾回收更早开始。

方法 2：增加老年代大小

• 通过参数 -Xmx 或 -XX:NewRatio 增加堆内存或调整新生代与老年代的比例，为老年代分配更多空间。

方法 3：启用内存压缩

• 在 CMS 回收后增加内存压缩阶段，减少碎片化：

  -XX:+UseCMSCompactAtFullCollection
  -XX:CMSFullGCsBeforeCompaction=<N>
  

第一个参数启用压缩，第二个参数设置多少次 Full GC 后进行压缩。

方法 4：监控和调整应用分配模式

• 通过监控发现是否有大量短生命周期的对象分配到老年代，可以优化代码逻辑，减少直接分配到老年代的频率。

方法 5：更换垃圾回收器

• 如果 CMS 无法满足需求，可以尝试 G1 GC，它能够自动进行内存压缩，避免碎片化问题。

4. 总结

concurrent mode failure 是 CMS GC 在垃圾回收期间因老年代空间不足而导致的失败。其根本原因在于老年代的内存不足、碎片化或启动时机不当。

关键点：

1. 提前启动 CMS 垃圾回收（降低 CMSInitiatingOccupancyFraction）。
2. 增加老年代内存，缓解内存压力。
3. 启用内存压缩，解决碎片化问题。
4. 监控和优化对象分配模式，减少老年代分配的压力。
   
   通过合理配置和优化代码逻辑，可以有效减少 concurrent mode failure 的发生。