老年代空间分配担保机制触发条件是Minor GC前检查老年代最大连续空闲空间是否大于历史平均晋升大小；仅Serial/Parallel Scavenge收集器启用，不满足则触发Full GC。
老年代空间分配担保机制触发的条件是什么
这是 JVM 在每次 Minor GC 前必须完成的一次关键判断：老年代是否“够用”，来容纳本次 GC 后可能晋升的对象。它不是可选逻辑，而是 HotSpot 的强制安全检查。
- 触发点只在
Minor GC开始前，且仅当使用Serial、Parallel Scavenge这类基于“复制算法”的年轻代收集器时才启用（G1、ZGC不走这套逻辑） - 判断依据是：老年代最大可用连续空间 > 历史上每次
Minor GC后进入老年代的平均大小（JVM 自动统计，存于_avg_promoted_size） - 如果不满足，JVM 会先尝试一次
Full GC来腾空间；若Full GC后仍不满足，就抛出java.lang.OutOfMemoryError: GC Overhead limit exceeded或直接java.lang.OutOfMemoryError: Java heap space
为什么明明老年代还有空间却还是触发 Full GC
常见现象是：堆总大小 4G，老年代已用 2.5G，剩余 1.5G，但 Minor GC 前仍强制 Full GC —— 这不是误判，而是“连续空间”和“预测晋升量”双约束的结果。
- 老年代碎片化严重，最大连续空闲块只有 800MB，而 JVM 预估本次晋升对象约 1.2GB（比如刚创建了一批大数组，或 Survivor 区对象年龄达到阈值批量晋升）
-
MaxTenuringThreshold设得过高（如 15），导致大量对象在 Survivor 中反复 copy，最终一次性涌向老年代，放大单次晋升压力 -
-XX:PretenureSizeThreshold未合理设置，本该直接进老年代的大对象（> 几百 KB）被塞进 Eden，撑爆后被迫全部晋升，打乱预估模型
如何验证当前是否正在执行分配担保检查
最直接的方式是打开 GC 日志并观察关键标记：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 加上
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，Minor GC 日志中出现Allocation Failure后紧跟着Full GC，大概率就是担保失败触发的 - 更明确的是开启
-XX:+PrintAdaptiveSizePolicy，你会看到类似这样的输出：PSYoungGen total 102400K, used 98304K [0x00000007c0000000, 0x00000007c6a00000, 0x00000007c6a00000) -> allocation failed. Attempting full collection. - 注意：
Parallel GC下这个检查不可关闭；想绕过？只能换收集器（如 G1），或者确保老年代足够大 + 碎片少（比如用-XX:+UseLargePages辅助降低碎片）
容易被忽略的三个实操细节
-
HandlePromotionFailure 这个 JVM 参数在 JDK 8u40 之后已被移除，现在它完全硬编码在 ParallelScavengeHeap::failed_mem_allocate 里，调不了 —— 别白费劲找开关
- 担保判断依赖历史晋升数据，所以新启动的应用前几次 Minor GC 很容易“误伤”：因为
_avg_promoted_size 还没稳定，JVM 会保守按 Eden 大小来预估，导致过早 Full GC
- 使用
-XX:+UseCompressedOops（默认开启）时，对象头压缩会影响指针寻址，间接让老年代实际可用连续空间比理论值略小，尤其在堆接近 32GB 临界点时，这点偏差会被放大
HandlePromotionFailure 这个 JVM 参数在 JDK 8u40 之后已被移除，现在它完全硬编码在 ParallelScavengeHeap::failed_mem_allocate 里，调不了 —— 别白费劲找开关_avg_promoted_size 还没稳定，JVM 会保守按 Eden 大小来预估，导致过早 Full GC-XX:+UseCompressedOops（默认开启）时，对象头压缩会影响指针寻址，间接让老年代实际可用连续空间比理论值略小，尤其在堆接近 32GB 临界点时，这点偏差会被放大事情说清了就结束
立即学习“Java免费学习笔记（深入）”；
