CMS发生Concurrent Mode Failure时，JVM立即中止并发周期并强制切换至Serial Old执行Full GC；该退化是硬编码的唯一兜底方案，采用标记-整理算法解决碎片问题，全程单线程STW，日志表现为concurrent mode failure后接Full GC及显著拉长的real耗时。
CMS 收集器发生并发失败（Concurrent Mode Failure）时，JVM 不会尝试继续当前 CMS 周期，而是立即中止所有并发阶段，强制切换到单线程、STW 式的 Full GC，并由 Serial Old 收集器执行回收。
触发即退化，不协商不重试
一旦检测到老年代剩余连续空间不足（无法容纳晋升对象或大对象），JVM 硬编码逻辑直接终止 CMS 的并发标记、预清理或并发清除等流程。这个决策是即时的、不可中断的，不会等待当前并发阶段完成，也不会尝试调用其他收集器替代。
- 退化动作发生在 JVM 内部判断“空间已不可用”的瞬间，无需用户干预
- 没有降级备选列表——Serial Old 是唯一被 JDK 8 及之前版本支持的兜底方案
- 即使系统有多核 CPU 或已启用其他 GC 相关参数（如 Parallel Old），该退化路径仍固定不变
Serial Old 执行标记-整理式 Full GC
退化后，Serial Old 会扫描整个堆（包括年轻代和老年代），采用标记-整理（Mark-Compact）算法，而非 CMS 原有的标记-清除。这一设计核心在于解决碎片问题：
- 先遍历所有存活对象并标记
- 再将存活对象向内存一端紧凑移动，消除中间空隙
- 最终释放连续的大块空闲空间，确保后续大对象可分配
正因为是单线程、全堆扫描、带压缩的 STW 过程，停顿时间明显拉长，常达数百毫秒至数秒。
日志与行为上的明确信号
该处理逻辑会在运行时留下稳定可识别的痕迹：
- GC 日志中紧随
[CMS-concurrent-mark: ...] (concurrent mode failure)出现[Full GC [Tenured: ...]或含SerialOld/Serial MarkSweepCompact字样 - 无任何并发阶段耗时统计（如缺失
CMS-concurrent-sweep行） -
[Times: user=..., real=...]中 real 时间远大于 user，且差值接近实际停顿长度 - 应用线程完全冻结，对外表现为响应延迟、超时、请求堆积
这不是容错，而是保护性熔断
退化机制本质是 JVM 在内存压力失控时的紧急制动，目的是防止 OOM 或持续分配失败：
- 它不优化吞吐，也不提升并发能力，只为恢复基本可用性
- 频繁触发说明 CMS 已无法匹配当前负载节奏，属于架构级预警
- 调参（如降低
-XX:CMSInitiatingOccupancyFraction）仅能延缓问题，不能改变退化逻辑本身
