“冒险”式Minor GC是指当老年代剩余空间小于新生代所有对象总大小但大于历史平均晋升量时，JVM在启用-XX:+HandlePromotionFailure前提下尝试执行的Minor GC；其依据是统计规律预判晋升风险低，失败后立即触发Full GC兜底。
什么是“冒险”式 Minor GC
当老年代剩余空间 小于新生代所有对象总大小，但 大于历史平均晋升量 时，JVM 仍可能允许执行 Minor GC——这就是“冒险”。它不是盲目放行，而是基于统计规律的预判：过去几次 Minor GC 后，实际晋升到老年代的对象平均只有 8MB，而当前老年代还剩 10MB，虽然理论上最坏情况（200MB 全部存活）会失败，但概率低，所以先试一试。
冒险的前提条件
触发冒险需同时满足：
- -XX:+HandlePromotionFailure 已启用（JDK 8+ 默认开启且不可关闭）
- 老年代空闲空间 ≥ 历史晋升平均大小（JVM 内部维护该滑动平均值）
- 老年代空闲空间 ＜ 新生代全部对象总大小（即不满足“安全担保”条件）
冒险失败后的真实处理流程
一旦 Minor GC 完成，发现晋升对象总量超出老年代可用空间，JVM 不会直接 OOM，而是立即触发 Full GC：
- Full GC 会清理整个堆（包括老年代），尝试腾出连续空间
- 若 Full GC 后老年代仍不足容纳本次晋升对象，才抛出 java.lang.OutOfMemoryError: Java heap space
- 注意：Parallel Scavenge 收集器在 Full GC 前还会额外做一次 Young GC（可通过
-XX:-ScavengeBeforeFullGC禁用）
为什么敢“冒险”？关键在统计稳定性
JVM 并非凭空猜测。它持续记录每次 Minor GC 后成功晋升到老年代的字节数，并计算加权平均值（例如最近 5 次的均值或最大值）。这个值反映的是真实负载特征：
- 若应用中短期对象占比高、存活率稳定，“平均晋升量”就很有参考价值
- 若某次突发大量长生命周期对象（如缓存预热、批量导入），导致晋升远超均值，就会触发 Full GC——这属于机制的正常兜底响应，而非设计缺陷
- 频繁冒险失败，往往暴露的是内存配置不合理或存在隐性泄漏，而非担保机制本身不可靠
