CMS发生Concurrent Mode Failure时，JVM立即中止并发阶段并退化为Serial Old执行Full GC，这是硬编码的保护机制而非可配置选项；需根治晋升过快、浮动垃圾多、触发过晚三类原因，长期应迁移到G1/ZGC等现代收集器。
CMS 发生 Concurrent Mode Failure（并发模式失败）时，JVM 不会尝试修复或重试当前 CMS 周期，而是立即中止所有并发阶段，退化为 Serial Old 执行 Full GC。这不是“问题需要解决”，而是 JVM 在内存压力失控时的硬编码保护机制——它本身已是最终应对动作。
退化行为是确定的，不是可配置的选项
一旦触发 Concurrent Mode Failure，HotSpot JVM（JDK 8 及之前）会强制启用 Serial Old 收集器，执行单线程、STW、标记-整理（Mark-Compact）式的 Full GC。这个路径被硬编码锁定，与 CPU 核心数、是否启用 Parallel Old 或其他 GC 参数无关：
- Serial Old 是唯一支持的兜底方案，因其标记-整理算法能压缩碎片，确保后续大对象分配成功
- 不会出现并行线程标识（如 [ParOldGen]），日志中仅见 [Tenured: ] 或 [SerialOld: ]
- GC 日志中缺失所有 CMS 并发阶段记录（如 CMS-concurrent-sweep），只有 Full GC 行及显著拉长的 real 耗时
真正要处理的不是“退化本身”，而是触发退化的根因
退化是信号，不是故障。频繁发生说明 CMS 已无法匹配当前负载节奏。需聚焦三类实际可干预因素：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 晋升速率突增：突发流量、缓存批量加载、JSON 序列化中间对象激增等，导致大量对象快速进入老年代
- 浮动垃圾失控：CMS 并发期间用户线程持续创建长生命周期临时对象（如无界缓存、密集日志输出），占用预留空间却无法本轮回收
- 触发时机太晚：-XX:CMSInitiatingOccupancyFraction 默认值可能达 75%～80%，留给 CMS 的清理窗口和安全余量严重不足
有效缓解手段：调参 + 行为控制
短期可降低退化频率，但无法消除 CMS 固有局限：
立即学习“Java免费学习笔记（深入）”；
- 显式设置 -XX:CMSInitiatingOccupancyFraction=50（建议 45–60），并搭配 -XX:+UseCMSInitiatingOccupancyOnly 禁用动态阈值调整
- 增大年轻代（-Xmn）或调高 SurvivorRatio，减少 Survivor 溢出导致的过早晋升
- 检查并限制无界缓存、避免在 CMS 并发周期内密集生成大对象或中间 byte[]/char[]
- 开启 -XX:+PrintTenuringDistribution 和 -XX:+PrintGCDetails，结合 jstat -gc
观察 OU（老年代使用率）与 YGC 频率联动关系
长期演进：放弃 CMS，迁移到更现代的收集器
CMS 在 JDK 9 中已被标记为废弃，JDK 14 后彻底移除。生产环境应评估升级路径：
- G1：自带增量压缩，天然抗碎片，通过 -XX:MaxGCPauseMillis 控制停顿目标，无需手动调优触发阈值
- ZGC 或 Shenandoah：亚毫秒级 STW，适用于超低延迟敏感场景，完全规避 Concurrent Mode Failure 类问题
