老年代空间分配担保机制是Minor GC前的安全检查机制，核心是用老年代最大连续空闲空间预判能否容纳新生代待晋升对象：先比对老年代连续空间是否≥新生代全部对象总大小；若不足，则参考历史晋升平均大小“冒险”执行Minor GC；失败则触发Full GC。
老年代空间分配担保机制不是“可开关的优化项”，而是 Minor GC 能否安全执行的前置守门员。一旦判断失误或配置失当，HandlePromotionFailure 就会从兜底逻辑变成崩溃导火索——不是 OutOfMemoryError，而是频繁 Full GC + STW 拉长、响应毛刺、甚至晋升失败直接卡死线程。
怎么确认当前 JVM 是否在走担保流程
最直接的方式是打开 GC 日志并观察 Minor GC 行为是否附带担保判断痕迹：
-
-XX:+PrintGCDetails必须开启，否则看不到晋升对象大小和老年代空闲连续空间的估算值 - 关注每次
GC (Allocation Failure)或GC (System)日志中是否出现类似Desired survivor size 1048576 bytes, new threshold 7 (max 15)后紧跟着Promotion failed或Failed to promote - 若日志里反复出现
Full GC (Ergonomics)紧跟在 Minor GC 后，大概率是担保失败后补救触发的 - JDK 8+ 默认启用
-XX:+HandlePromotionFailure，但不等于担保总成功；禁用它（-XX:-HandlePromotionFailure）会让所有担保失败直接跳 Full GC，反而掩盖问题
为什么“老年代连续空闲空间”比“总空闲空间”关键
担保机制检查的是最大一块连续空闲内存，不是碎片加总。哪怕老年代用了 40%，剩下 60% 全是 100KB 的碎片块，也撑不住一个 2MB 的晋升对象。
- 常见诱因：长期运行后 CMS 收集器未开启
-XX:+UseCMSCompactAtFullCollection，或 G1 未调优-XX:G1HeapRegionSize导致大对象无法落库 - 验证方法：用
jstat -gc <pid></pid>查看OU（Old Used）和OC（Old Capacity），再用jmap -histo:live <pid></pid>+jmap -dump配 MAT 分析碎片分布 - 注意：
Parallel Old和G1在 Full GC 时会压缩，但 Minor GC 担保阶段不压缩——它只读当前快照
如何用参数控制担保行为而不误伤吞吐
盲目调大 Survivor 或缩小 Young 区可能治标不治本，关键是让担保预估更准、失败代价更低：
- 用
-XX:TargetSurvivorRatio=90（默认 50）提升 Survivor 利用率，减少“明明能装下却因阈值低提前晋升”的误判 - 通过
-XX:MaxTenuringThreshold把年龄阈值设为 15（CMS）或 6（G1 默认），避免短命对象过早挤占 Survivor 空间 - 对已知的大对象（如缓存批量加载的 byte[]），显式用
-XX:PretenureSizeThreshold=2097152（2MB）让它直入老年代，绕过担保链路 - 禁用
-XX:-UseAdaptiveSizePolicy，固定-Xmn和-XX:SurvivorRatio，避免 JVM 动态调参导致历史晋升均值失真
担保失败日志里藏着哪些关键数字
真正有用的不是“Promotion failed”这行字，而是它前后三行里的数值对比：
- Minor GC 前日志中
PSYoungGen行的used值（比如12345K->678K），减去箭头后值，就是本次待晋升对象总大小 ≈11667K - 同次日志中
ParOldGen行的capacity减used得到总空闲，但需结合jstat -gccapacity <pid></pid>的NGCMN/NGCMX推算连续块上限 - 如果日志里有
Average promotion size = 8.2MB这类统计，说明 JVM 正在用历史均值做担保判断——此时应检查最近 5 次 Minor GC 的晋升量是否突增 - 特别注意
concurrent mode failure（CMS）或to-space overflow（G1）这类错误，它们常被误认为是担保失败，实则是收集器自身并发缺陷
担保机制本身不产生性能开销，但它的判断依据（历史晋升均值、连续空间扫描）依赖于稳定的应用行为。一旦对象存活率突变、或老年代碎片悄然累积，担保就会从安全阀变成雪崩起点——这时候看日志比调参更重要，而看懂日志里那几行数字的含义，比堆参数多加两个零管用得多。
