Serial Old 是 CMS 并发失败时 JVM 硬编码退化的唯一兜底方案，单线程执行全堆标记-整理 Full GC，全程 STW，用于解决因碎片或空间不足导致的 Allocation Failure。
Serial Old 收集器在 CMS 发生 Concurrent Mode Failure 时，不是“配合使用”，而是硬编码退化执行的唯一兜底方案——它不参与 CMS 的正常流程，只在 CMS 完全失效的瞬间被 JVM 强制拉起，接管整个堆的回收任务。
CMS 失败时 Serial Old 是自动触发、不可绕过的
一旦 JVM 检测到老年代剩余连续空间不足以支持新晋升对象或大对象分配（即触发 Concurrent Mode Failure），会立即中止所有 CMS 并发阶段（标记、预清理、清除等），不再等待、不协商、不重试。此时：
- 所有应用线程 STW（Stop-The-World）
- JVM 内部直接调用 Serial Old 执行 Full GC
- 该行为由 HotSpot 固定实现，不受 -XX:+UseParallelOldGC 等参数影响
- 即使机器有 32 核 CPU，Serial Old 仍只用单线程工作
Serial Old 在这次退化中干了什么
它执行的是全堆、单线程、标记-整理（Mark-Compact）式 Full GC：
- 扫描年轻代 + 老年代全部对象，标记存活实例
- 将所有存活对象向内存一端紧凑移动，消除碎片
- 释放出大块连续空闲空间，解决 CMS 标记-清除导致的分配失败问题
- 正因为要移动对象+全堆扫描，STW 时间显著拉长（常达数百毫秒至数秒）
日志里怎么识别这个过程
这是最明确的信号，无需额外监控工具：
立即学习“Java免费学习笔记（深入）”；
- 日志中先出现
[CMS-concurrent-mark: ...] (concurrent mode failure) - 紧接着就是
[Full GC (Allocation Failure) [Tenured: ...]或含SerialOld/MarkSweepCompact字样 - 没有后续的
CMS-concurrent-sweep等并发阶段记录 -
[Times: user=..., real=...]中 real 耗时远大于 user，差值≈实际停顿时间
这不是配置问题，而是架构预警信号
频繁出现 Concurrent Mode Failure + Serial Old Full GC，说明 CMS 已无法匹配当前负载节奏：
- 不是调高
-XX:CMSInitiatingOccupancyFraction就能根治（反而可能更早触发失败） - 应优先检查：晋升速率是否突增、浮动垃圾是否过多（如 JSON 解析、日志打点）、老年代碎片是否严重
- 长期方案建议升级到 G1 或 ZGC；若必须用 CMS，需显式设
-XX:CMSInitiatingOccupancyFraction=50 -XX:+UseCMSInitiatingOccupancyOnly并持续观察jstat -gc <pid>中 OU 和 YGC 频率
