请解释在 Java 虚拟机中，CMS（Concurrent Mark Sweep）垃圾收集器发生 Concurrent Mode Failure 时，触发的 Full GC 为什么是单线程的？
考察说明
考查对 CMS 收集器工作机制、Concurrent Mode Failure 触发条件及其后果的深入理解。
回答思路
- 【回答框架 1】CMS 主要目标是降低停顿，其标记和清理阶段多与用户线程并发。当并发阶段无法及时回收老年代，出现 Concurrent Mode Failure 时，CMS 无法继续，转而采用备用方案。
- 【回答框架 2】备用方案是使用 Serial Old 收集器进行 Full GC。Serial Old 采用单线程、标记-整理算法，全程 Stop The World，因此表现为单线程。
- 【回答框架 3】原因在于 CMS 设计时将复杂度集中于并发部分，后备方案选择简单可靠的单线程 Serial Old，且当年硬件多为单核，单线程 Full GC 简单且能保证正确性。
- 【回答框架 4】该单线程 Full GC 停顿时间较长，反映了 CMS 在并发失败情况下的退化行为。最终 CMS 在 JDK 9 后被废弃，在 JDK 14 移除，由 G1 等替代。
- 【关键点 1】Concurrent Mode Failure 是 CMS 并发阶段无法及时回收，触发备用 Full GC。
- 【关键点 2】备用 Full GC 使用 Serial Old 收集器，单线程、标记-整理，全程 STW。
- 【关键点 3】CMS 并发阶段失败后无法继续，必须退化为简单可靠的 Full GC。
- 【关键点 4】CMS 已被移除，推荐使用 G1 或 ZGC。
- 【易错点 1】不要混淆 Parallel Scavenge 和 Serial Old，备用收集器是 Serial Old。
- 【易错点 2】不要误认为 CMS 的 Full GC 是并发或并行，实际是单线程。
- 【易错点 3】避免过度强调单线程劣势，忽略其备用性和可靠性设计。