-XX:+HandlePromotionFailure开启基于历史均值的担保尝试：先查老年代最大连续空闲空间是否≥待晋升对象总大小，不满足则用近期晋升均值二次判断，避免盲目Full GC。
老年代担保机制不是“预防崩溃”的保险丝，而是 Minor GC 前的一次空间预检——它不阻止崩溃，只决定要不要提前触发 Full GC。 真正的崩溃（如 java.lang.OutOfMemoryError: Java heap space）往往发生在担保失败且 Full GC 也清不出足够空间时。所以关键不是“启用担保”，而是让担保判断更准、更早暴露风险。
怎么理解 -XX:+HandlePromotionFailure 的实际作用
这个参数在 JDK 8+ 已默认开启，但它不表示“允许冒险晋升”，而是开启“基于历史均值的担保尝试”。JVM 会做两件事：
- 检查老年代最大连续空闲空间是否 ≥ 当前新生代所有对象总大小（含 Eden + From Survivor 中待处理对象）——满足则直接晋升，安全
- 不满足时，再查过去几次 Minor GC 晋升到老年代的对象平均大小；若该均值 ≤ 老年代连续空闲空间，则“冒险”执行本次 Minor GC，否则直接触发 Full GC
注意：-XX:-HandlePromotionFailure（禁用）在现代 JVM 中基本无意义，禁用后只要老年代空间不足，就必然 Full GC，反而更激进。
为什么看“连续空闲空间”比“总空闲空间”更重要
老年代使用标记-清除算法，长期运行后极易产生内存碎片。即使 jstat -gc 显示老年代还有 40% 空闲，但若最大连续块只有 50MB，而本次 Minor GC 预估要晋升 120MB 对象，担保就会失败。
- 用
jmap -histo:live <pid></pid>或jcmd <pid> VM.native_memory summary</pid>无法反映连续性，得靠 GC 日志里的concurrent mode failure或promotion failed判断 - 如果日志频繁出现
PSYoungGen: [Eden: ...->0K(…), From: …->…K(…), To: …K(…)]后紧跟着ParOldGen: [used: …K, capacity: …K, committed: …K]且used接近capacity，说明碎片已在积累 - G1 / ZGC 等区域化收集器不依赖此机制，但 Parallel GC 和 CMS 严重受制于此
如何通过 GC 日志定位担保失败的真实诱因
打开 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 后，重点盯三类线索：
- Minor GC 日志末尾是否带
(promotion failed)—— 这是担保失败的直接证据 - Full GC 触发前是否有
Allocation Failure或Concurrent Mode Failure—— 表明老年代已无连续空间可借 - 对比两次 Minor GC 间老年代
used增量与晋升对象估算值：若used增长远小于估算值，说明部分对象被丢弃或触发了降级分配（如大对象绕过新生代）
示例日志片段：2026-04-28T12:15:22.331+0000: 12345.678: [GC (Allocation Failure) [PSYoungGen: 892345K->12345K(917504K)] 1234567K->345678K(2097152K), 0.0456789 secs] [Times: user=0.12 sys=0.01, real=0.05 secs]
这里 1234567K->345678K 是整个堆变化，差值约 890MB 晋升，若老年代当时最大连续块仅 600MB，就必然失败。
真正能降低担保失败风险的实操动作
调参不能绕过物理限制，但可以压缩误判窗口：
- 用
-XX:PretenureSizeThreshold=1048576（1MB）让大数组直入老年代，避免它们挤占 Survivor 并放大晋升压力 - 适当调低
-XX:MaxTenuringThreshold（如设为 4），让中龄对象早进老年代，减少单次 Minor GC 晋升总量 - 监控
SurvivorUsage（通过 JMX 的MemoryPoolUsage）：若每次 Minor GC 后 To Survivor 使用率长期 >90%，说明 Survivor 太小或对象存活率异常高，需调整-XX:SurvivorRatio或排查内存泄漏 - 避免在 Minor GC 高频期做批量数据加载——这类操作常导致 Eden 瞬间打满，Survivor 来不及承接，直接触发担保检查
最易被忽略的一点：担保机制只看“老年代有没有地方放”，从不检查“放进去之后老年代会不会立刻满”。所以即使担保成功，下一次 Minor GC 前老年代可能已无余量——这需要靠 ParOldGen 的使用率趋势监控来补位，而不是依赖单次担保结果。
