晋升失败是老年代内存严重碎片化的临床指征，需通过验证老年代使用率与碎片率、晋升对象大小分布、PSOldGen回收差值三大指标定位问题，阻断缓存无上限、DirectByteBuffer泄漏、类加载器泄漏三类源头，并用G1参数组合强制整理，最终以碎片率＜12%、晋升失败归零、Full GC频次降50%为解结标志。
晋升失败（Promotion Failed）不是GC日志里的普通告警，它是老年代内存已“病入膏肓”的临床指征——表面是对象搬不进老年代，根子在碎片化已严重侵蚀分配能力。要一针见血破除这个死结，关键不是调大堆内存，而是直击碎片成因、切断累积路径、验证回收实效。
盯住晋升失败背后的三个硬指标
单看“Promotion Failed”字样容易误判。必须同步交叉验证三项日志数据：
- 老年代使用率 + 碎片率：Full GC后老年代剩余空间＜10%，且GCeasy报告Fragmentation＞25%，说明空间虽有但无法连续分配；
- 晋升对象大小分布：日志中出现“10M objects could not be promoted”这类提示，结合-XX:+PrintGCDetails中的survivor occupancy，可判断是否大对象批量溢出（如未设-XX:PretenureSizeThreshold）；
- PSOldGen/ParOldGen的回收前后差值：例如[PSOldGen: 850M->849M(1024M)]，仅回收1MB，R＜0.001，说明GC根本没腾出有效空间，纯属无效清扫。
从根源切断碎片生成链路
碎片不是凭空产生，而是由特定行为持续喂养。优先排查并阻断以下三类高频源头：
- 长生命周期缓存未设上限：检查代码中static Map/ConcurrentHashMap是否无淘汰策略，尤其YARN容器内Spark/Hive任务状态缓存；
- DirectByteBuffer未及时清理：NIO操作频繁但未调用cleaner或System.gc()触发释放，导致老年代堆外映射残留；
- 类加载器泄漏：热部署场景下旧ClassLoader未被回收，其加载的Class元数据永久驻留Metaspace，间接挤压老年代可用空间。
用参数组合拳强制“压碎再重组”
对已形成的高碎片老年代，CMS已无力回天。切换至G1或ZGC是治本之策，但若暂不能升级JVM，可临时启用以下参数组合倒逼整理：
- -XX:+UseG1GC -XX:G1HeapRegionSize=1M：小Region提升跨区大对象分配成功率，降低晋升失败概率；
- -XX:MaxGCPauseMillis=200 -XX:G1MixedGCCountTarget=8：让混合GC更早、更频繁介入老年代整理；
- 禁用-XX:-UseAdaptiveSizePolicy：关闭自适应策略，防止GC自动缩小老年代导致碎片加剧。
验证是否真解除了死结
优化后不能只看“Promotion Failed”消失，要确认碎片逻辑已被打破：
- 连续3次Full GC后，老年代碎片率稳定＜12%（GCEasy报告）；
- 晋升失败日志归零，且Young GC后PSOldGen占用增长平缓（非阶梯式跳变）；
- 同一业务高峰期，Full GC频次下降50%以上，平均停顿时间＜300ms。
碎片化死结的本质，是内存分配与回收节奏长期失配。晋升失败就是那个不容忽视的红色报警灯——它不骗人，也不妥协，只等你顺着日志线索，一层层剥开应用行为、JVM机制和资源配置的嵌套问题。
