老年代担保失败是jvm在minor gc前预判风险后主动触发full gc的结果，关键在于检查时机（gc前）、判断依据（连续空闲空间≥晋升量或历史均值）和退路选择（直接full gc而非补救）。
老年代担保失败不是“突然出错”，而是JVM在Minor GC前就已预判风险并按规则退守的结果。理解它，关键不在背流程，而在看清三个层次：检查时机、判断依据、退路选择。
担保检查发生在Minor GC之前，不是之后
很多人误以为“GC执行中发现放不下才报错”，其实完全相反。JVM在每次Minor GC启动前，就完成两轮关键估算：
- 第一层：看老年代最大连续空闲空间是否 ≥ 新生代所有对象总大小（极端假设——Eden+From全存活）
- 第二层：若不满足第一层，则查历史晋升均值（JVM内部维护，不打印），再比对老年代当前最大连续空闲空间是否 ≥ 该均值
只要任一层不通过，且-XX:+HandlePromotionFailure启用（JDK8+默认开启），JVM就放弃本次Minor GC，直接触发Full GC——这不是失败后的补救，而是提前规避。
变量晋升规则随JDK版本和GC算法有实质差异
所谓“变量晋升”，实为对象年龄达标或条件触发后从Survivor进入老年代的过程。不同版本/收集器逻辑不同：
- Serial/Parallel收集器（JDK7~8主流）：严格依赖-XX:MaxTenuringThreshold（默认15）。对象每经历一次Minor GC年龄+1，达阈值即晋升；但还叠加“动态年龄判定”：若某次GC后，Survivor中某年龄及以上对象总和 > Survivor容量50%，则该年龄对象全部晋升
- CMS收集器（JDK7~8）：同样支持上述规则，但因不整理内存，老年代碎片严重，“最大连续空闲空间”极易不足，导致担保失败频发；日志中常见promotion failed字样
- G1收集器（JDK9+默认，JDK7u40起可用）：不再用统一年龄阈值，改由-XX:G1MaxNewSizePercent等参数调控新生代弹性大小；晋升更依赖Remembered Set与Mixed GC主动回收高收益Region；担保逻辑弱化为Region级“预留空间检查”，不依赖全局连续空间
- ZGC/Shenandoah（JDK11+）：彻底摒弃分代担保概念，采用并发标记与染色指针，对象可跨代直接分配，无传统晋升路径
真正决定担保成败的，是连续空间而非总空闲
这是最常被忽略的核心。JVM不看“老年代还剩多少MB”，而看“其中最大的一块连续空闲区域有多大”。例如：
- 老年代总空闲200MB，但被碎片切成10块，每块最大仅12MB
- 本次Minor GC预计晋升对象约80MB（历史均值）
- 即使200MB > 80MB，但12MB
这种现象在CMS下极典型；G1虽缓解，但Humongous对象（>½ Region）仍需连续Region，也可能触发类似失败。观察GC日志时，要重点关注concurrent-cycle-init（CMS）或mixed GC是否及时启动——若迟迟不出现，说明碎片已在堆积，连续空间正悄悄缩水。
