为什么 Java 中 CMS 垃圾收集器在发生 Concurrent Mode Failure 时的 Full GC 是单线程的？

在 CMS（Concurrent Mark-Sweep）垃圾收集器中，当发生 Concurrent Mode Failure 时，JVM 会执行一次 Full GC。与并发多线程的垃圾回收相比，这种 Full GC 是单线程的，导致暂停时间显著增加。

以下是具体原因及原理分析：

1. CMS 的设计目标

CMS 的核心目标是 低停顿，通过并发执行标记和清除阶段，与应用线程同时运行，最大限度地减少垃圾回收引起的停顿。然而，CMS 的标记-清除算法本质上 不进行内存压缩，因此在某些情况下（如内存碎片严重或空间不足），CMS 无法完成任务，从而触发 Concurrent Mode Failure。

2. Full GC 的触发原因

当 CMS 失败时，老年代空间不足，无法存放新分配或晋升的对象，这时 JVM 只能退而求其次，执行一次 Full GC 来回收整个堆空间。这种 Full GC 的特点是：

暂停所有应用线程（Stop-The-World）。
使用单线程执行标记、清理和内存整理操作。

3. 为什么 Full GC 是单线程的？

CMS 的 Full GC 是基于 Serial Old GC 的单线程实现，其设计原因如下：

原因 1：CMS 的备用策略

CMS 是为低延迟场景设计的，但它的设计并不适合 Full GC。当 CMS 失败时，JVM 转而调用传统的 Serial Old GC 作为备用策略。Serial Old GC 是单线程的，因此 CMS 的 Full GC 也只能是单线程。

原因 2：内存压缩需求

CMS 本身不支持 内存压缩（Compact），而 Full GC 在清理垃圾的同时，还需要对内存进行压缩以消除碎片化问题。这种压缩操作涉及对象移动和引用更新，较为复杂，单线程执行可以避免多线程同步带来的额外开销。

原因 3：历史兼容性

早期的 JVM 中，Serial Old GC 是默认的老年代垃圾回收器。当 CMS 失败时，JVM 选择直接使用现有的 Serial Old GC 实现 Full GC，而没有针对多线程优化。

原因 4：代码复杂性与性能权衡

在设计 CMS 时，Full GC 被视为一种 非常规操作，只在少数情况下触发。因此，JVM 没有对 CMS 的 Full GC 实现多线程优化，因为这会显著增加代码复杂性，而收益有限。

4. Full GC 的影响

Full GC 是单线程的，因此其执行时间较长，会显著增加应用的停顿时间。这对于低延迟应用是不利的。以下是其典型影响：

应用暂停时间从毫秒级增加到秒级。
高并发环境下会导致性能抖动。

5. 如何避免 Full GC？

为避免 Concurrent Mode Failure 和 Full GC 的发生，可以采取以下措施：

调整 CMS 启动阈值：
- 使用 -XX:CMSInitiatingOccupancyFraction=<N> 提前启动 CMS 回收，避免内存空间被耗尽。
增加老年代大小：
- 调整 -Xmx 和 -XX:NewRatio，为老年代分配更多内存空间。
优化对象分配和晋升：
- 减少长生命周期对象直接分配到老年代，优化代码逻辑，降低新生代到老年代的晋升压力。
启用内存压缩：
- 使用 -XX:+UseCMSCompactAtFullCollection 启用内存压缩，减少碎片化问题。
使用其他垃圾回收器：
- 如果应用无法接受 CMS 的 Full GC 停顿时间，可以尝试使用 G1 GC 或其他现代垃圾回收器（如 ZGC、Shenandoah），这些回收器更适合低延迟场景。