promotion failed 表明 cms 老年代内存碎片化严重——空间充足却无法分配连续内存；典型表现为年轻代零回收、老年代剩余多仍失败、随即触发 concurrent mode failure。
看到 Promotion Failed，基本可以断定 CMS 已陷入内存碎片化死结——不是老年代没空间，而是有空间却拼不出一块够大的连续区域来装下要晋升的对象。大变量（如大数组、长字符串、缓存块）是碎片的“显影剂”，它们一出现，就把隐藏的碎片问题直接引爆。
从日志里揪出碎片化的铁证
别只盯着“failed”四个字，重点比对三组数字：
-
年轻代几乎零回收：日志中出现
[ParNew (promotion failed): 146112K->146112K(153600K)]，说明 GC 后年轻代使用量没变，对象全卡在 Eden/Survivor 里，等着“一步到位”进老年代，但被拦住了； - 老年代剩余充足却报错：比如日志显示老年代已用 8.2G / 总 12G（剩余近 4G），仍触发 Promotion Failed——这说明剩余空间是碎的，无法满足单次几百 KB 甚至几 MB 的连续分配需求；
-
紧随其后的 Concurrent Mode Failure：Promotion Failed 往往很快引发
CMS-concurrent-mark (concurrent mode failure)，意味着 CMS 还没来得及并发清理，老年代就因碎片+新对象涌入彻底失守，被迫退化为 Serial Old 全停顿回收。
用参数让碎片无处藏身
光看日志不够，得让 JVM 把碎片行为“说出来”：
- 加
-XX:+PrintTenuringDistribution：观察每次 YGC 后 age=1 或 age=2 就出现 MB 级对象，说明大变量根本没在 Survivor 多待，直奔老年代，加剧碎片； - 开
-XX:+PrintGCDetails -XX:+PrintHeapAtGC：对比 GC 前后老年代使用量，若单次突增 200MB+ 且伴随 Promotion Failed，基本锁定大对象集中晋升； - 配合
jstat -gc <pid> 1000 5</pid>：重点关注S0U/S1U 持续≈0和OU（Old Used）阶梯式跳涨，这是对象绕过 Survivor 直接晋升的实锤。
打破死结不靠调大堆，而靠控源头、疏路径、压碎片
CMS 本身不整理老年代，所以优化必须前置：
- 拦截大对象：用
-XX:PretenureSizeThreshold=512k（Parallel GC）或改用 G1 并设-XX:G1HeapRegionSize=1M，让大对象直接进老年代或 Humongous 区，避开年轻代晋升路径； - 缩短大变量生命周期：查代码里
new byte[1024*1024*10]、未及时close()的流式解析、长期持有的报表缓存，改用对象池、分片处理或软引用； - 主动触发碎片治理：加
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1，让每次 Full GC 都做压缩（代价是更长停顿，但可破死循环）。
CMS 的 Promotion Failed 不是偶然故障，而是碎片积累到临界点的必然爆发。日志里的每一处“failed”，都在提示你：该清理大变量了，该换回收器了，或者该重构内存模型了。
