Concurrent Mode Failure 表明 CMS 未及时清理老年代而被迫退化为 Serial Old 执行 Full GC，日志特征为出现“concurrent mode failure”字样后紧跟 Full GC（Cause 为 Allocation Failure 或 CMF），且 CMS 并发阶段中断、无 sweep/reset 记录。
看到 Concurrent Mode Failure 就说明 CMS 回收器在并发清理过程中“没抢赢”，被迫退化为 Stop-The-World 的 Full GC。
关键日志特征
不是所有带“concurrent”字样的日志都代表失败，要盯紧这几个信号：
- 日志中明确出现 concurrent mode failure 或 Concurrent Mode Failure（大小写不敏感，可能夹杂空格或标点）
- 该字样后紧跟 Full GC，且 Cause 字段常为 Allocation Failure 或直接写 CMF
- CMS 并发周期被截断：比如看到
[CMS-concurrent-abortable-preclean: ...]，但后续没有cms-concurrent-sweep或cms-concurrent-reset阶段，直接跳到 Full GC - 老年代使用率（OU）在触发 CMS 前已接近甚至超过
-XX:CMSInitiatingOccupancyFraction设定值（如设了 70，而日志显示 OU=72K/1024K）
怎么快速定位这行日志
用文本工具搜索以下组合更可靠：
-
concurrent.*failure（正则匹配，覆盖大小写和空格变体） -
Full GC.*CMF或Full GC.*Concurrent Mode - 配合时间戳比对：前一条是 CMS-initial-mark，下一条却是 Full GC，中间缺了并发阶段 —— 这就是中断证据
别被假象误导
这些情况 不算 Concurrent Mode Failure：
- 只有
CMS-concurrent-mark或CMS-concurrent-sweep正常完成的日志 - 出现
Promotion Failed或Allocation Failure但没提 CMF —— 那是年轻代晋升问题或直接分配失败 - 日志里有
concurrent但上下文是 G1 或 ZGC（CMS 已在 JDK 14 移除，新环境不会出现）
顺手确认是否真在用 CMS
检查 JVM 启动参数是否有 -XX:+UseConcMarkSweepGC；若用的是 -XX:+UseG1GC 或 -XX:+UseZGC，那日志里绝不会出现 CMF —— 此时看到类似字样，大概率是日志误读或旧配置残留。
