分配担保机制的核心作用是Minor GC前预判老年代能否容纳晋升对象以避免Full GC；它分两步判断：先比对老年代最大连续空闲空间与新生代全部存活对象总大小，不满足则再比对与历史平均晋升大小，任一不通过即触发Full GC。
分配担保机制的核心作用，是让 Minor GC 在执行前“预判”老年代是否能容纳即将晋升的对象，从而避免因空间不足而被迫升级为 Full GC。
担保机制的两步预判逻辑
虚拟机在每次 Minor GC 前会做两次判断：
- 第一步：检查老年代最大连续可用空间是否 ≥ 当前新生代所有存活对象总大小。若成立，Minor GC 可安全执行，不触发 Full GC。
- 第二步：若第一步不成立，但开启了担保（-XX:+HandlePromotionFailure 默认开启），则对比老年代最大连续可用空间与“历史晋升对象平均大小”。若大于该平均值，就冒险执行 Minor GC；否则直接退回到 Full GC。
为什么能减少 Full GC 次数
关键在于它把“全堆扫描+整理”的代价，换成了更轻量的“提前估算+局部回收”：
- 多数 Minor GC 后只有少量对象真正晋升，远小于新生代总对象量，用历史平均值估算比直接按总量判断更贴近真实压力。
- 避免了只要老年代剩余空间略小于 Eden+Survivor 总量，就无差别触发 Full GC 的激进策略。
- 即使冒险失败（晋升对象实际体积超过预期），也只是触发一次 Full GC，而不是每次 Minor GC 都触发。
实际影响场景举例
比如 Survivor 区太小，一批 2MB 对象无法容纳，必须晋升到老年代：
- 若老年代空闲连续空间为 5MB，而这批对象共 3MB → 第一步通过，直接 Minor GC。
- 若老年代空闲连续空间仅 4MB，但过去 5 次晋升平均为 2.3MB → 第二步通过，仍尝试 Minor GC。
- 若空闲空间仅 2MB，且历史平均为 2.8MB → 不满足任一条件，跳过 Minor GC，直接 Full GC。
调优注意点
担保机制有效依赖于稳定的历史数据和合理配置：
- 确保 -XX:+HandlePromotionFailure 未被关闭（HotSpot 默认开启）。
- 避免 SurvivorRatio 设置过小，导致大量对象频繁“挤出”Survivor，人为放大晋升压力。
- 观察 GC 日志中 promotion failed 出现频率——高频说明老年代碎片化严重或晋升量波动大，此时担保容易失败。
- 大对象（≥ -XX:PretenureSizeThreshold）直接进老年代，绕过新生代，也会影响晋升统计的代表性，需一并评估。
