对象分配担保机制是Minor GC前由GC系统自动执行的担保检查，用于预估晋升对象大小并与老年代空间比较，若不足则触发Full GC以避免OOM。
对象分配担保机制（Allocation Guarantee）并不是在 Minor GC 前主动触发的，而是当 JVM 判断一次 Minor GC 后，**存活对象可能无法全部晋升到老年代（如老年代空间不足）时，在 Minor GC 过程中或即将开始前，由 GC 系统自动发起的一次“担保检查”**。它本质上是一种安全保护策略，防止因晋升失败导致 Full GC 或 OOM。
什么是对象分配担保机制
该机制的核心逻辑是：Minor GC 后，Eden 和 Survivor 中的存活对象需要晋升（Promotion）到老年代。但老年代剩余空间不一定足够容纳所有待晋升对象。JVM 会预先估算本次晋升所需的内存，并与老年代可用空间比较：
- 若老年代可用空间 ≥ 历史平均晋升大小（或当前预估晋升量），则允许 Minor GC 正常进行；
- 若不满足，且设置了 -XX:+HandlePromotionFailure（JDK 7 及以前默认开启，JDK 8+ 默认开启，G1/ZGC 不适用），JVM 就会尝试“担保”——先触发一次 Full GC 来腾出老年代空间，再执行 Minor GC；
- 若担保失败（如 Full GC 后仍不够），则抛出
java.lang.OutOfMemoryError: GC overhead limit exceeded或直接java.lang.OutOfMemoryError: Java heap space。
它如何“在 Minor GC 前”被感知和介入
严格来说，这不是一个独立可调用的“触发动作”，而是在 Minor GC 的准备阶段（GC Roots 扫描前）由 GC 算法内部完成的快速判断。以 Parallel Scavenge / CMS（ParNew）为例：
- JVM 统计最近几次 Minor GC 晋升到老年代的对象平均大小（
avg_promoted）； - 结合当前 Eden 区使用量、Survivor 中的存活对象，预估本次待晋升总量；
- 查询老年代最大连续空闲空间（
concurrent mode failure场景下还要考虑碎片）； - 若预估晋升量 > 老年代可用连续空间，且
HandlePromotionFailure开启，则放弃本次 Minor GC 计划，转而启动 Full GC——这个决策发生在 Minor GC 实际标记/清理动作之前。
影响担保是否生效的关键参数
- -XX:+HandlePromotionFailure：启用分配担保（HotSpot 默认开启，无需显式配置）；
- -XX:MaxTenuringThreshold：影响对象何时晋升，间接改变晋升时机和批量；
- -XX:PretenureSizeThreshold：大对象直接进老年代，绕过年轻代，减少晋升压力；
- -XX:SurvivorRatio 和 -XX:InitialTenuringThreshold：影响 Survivor 容量和晋升年龄阈值，从而影响每次 Minor GC 后有多少对象符合晋升条件。
实际观察与验证方法
可通过 GC 日志确认担保行为是否发生：
立即学习“Java免费学习笔记（深入）”；
- 出现
Desired survivor size ... bytes, new threshold ...表示正常晋升计算； - 若日志中 Minor GC 后紧跟着 Full GC，且无明显大对象分配，很可能是担保失败触发；
- 添加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注
PSYoungGen和ParOldGen的前后变化； - 使用 jstat -gc <pid> 观察
S0C/S1C/EC/OC和YGC/YGCT/FGC/FGCT，突增的 FGC 配合年轻代频繁 GC 是典型信号。
