GC 日志中 Promotion Failed 指出 CMS 内存碎片化问题

CMS垃圾回收器中的“Promotion Failed”并非单纯内存不足，而是老年代严重内存碎片化的明确信号——即便剩余空间充足，也无法凑出足够连续的内存块来容纳从年轻代晋升的大对象；它常伴随年轻代零回收、老年代高使用率却仍失败、以及紧随其后的Concurrent Mode Failure，暴露出大对象直入老年代、Survivor区形同虚设等深层问题；解决关键不在于盲目调大堆内存，而在于通过JVM参数精准定位碎片根源、拦截大对象晋升路径、缩短大变量生命周期，并在必要时借助压缩式Full GC或升级至G1等更适应现代应用内存特征的回收器。

看到 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 1000 5：重点关注 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”，都在提示你：该清理大变量了，该换回收器了，或者该重构内存模型了。

到这里，我们也就讲完了《GC 日志中 Promotion Failed 指出 CMS 内存碎片化问题》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！