minor gc 不等于 full gc，但常是其导火索：每次 minor gc 后存活对象晋升老年代，若老年代空间不足（如晋升失败、担保检查不通过）或元空间耗尽，即触发 full gc。
Minor GC 本身不等于 Full GC，但它常常是 Full GC 的“导火索”。二者不是孤立事件，而是在分代模型下紧密协作、相互影响的回收环节。
Minor GC 是老年代压力的直接来源
每次 Minor GC 后，存活对象会晋升到老年代——这是分代设计的核心逻辑。但晋升不是无条件的：
- 对象年龄达阈值（默认15次）或 Survivor 区同龄对象超50%，触发晋升
- Survivor 空间不足时，直接“担保晋升”，大量对象一次性涌向老年代
- 大对象绕过年轻代，直接分配进老年代，加剧空间消耗
如果老年代本身已接近饱和，一次常规 Minor GC 就可能因晋升失败（Promotion Failure）直接触发 Full GC。
空间分配担保机制让 minor GC 可能“跳过”自身流程
JVM 在 Minor GC 开始前会做一次关键检查：老年代剩余连续空间是否 ≥ 历次晋升对象的平均大小。这个检查叫“空间分配担保”。
- 若不满足，且未禁用担保（-XX:+HandlePromotionFailure 默认开启），则跳过 Minor GC，直接触发 Full GC
- 若禁用担保，Minor GC 照常执行，但晋升时发现老年代放不下，就会抛出
java.lang.OutOfMemoryError: Java heap space
也就是说，Minor GC 是否真正执行，取决于老年代的“信用额度”。它本质是一次带前置风控的回收动作。
高频 minor GC 会加速元空间和类卸载压力
虽然 Minor GC 不扫描元空间，但频繁的年轻代回收往往伴随高动态行为：
- Spring AOP、CGLib 代理、Groovy 脚本等持续生成新类 → 元空间持续增长
- ClassLoader 未被及时回收 → 类元数据无法卸载
- 一旦元空间触及 -XX:MaxMetaspaceSize，JVM 必须执行 Full GC 来尝试卸载无用类
此时 Full GC 并非因堆内存满，而是为腾出元空间——而驱动这一过程的，往往是背后高频、短生命周期的对象分配模式，即 Minor GC 的典型场景。
收集器差异放大协作效应
不同 GC 算法对 Minor→Full 的传导敏感度不同：
- CMS 在并发清理阶段若遇到老年代分配请求失败，立即退化为 Serial Old，等效 Full GC
- G1 的 Mixed GC 若无法及时回收足够老年代 Region，会降级为单线程 Full GC
- ZGC/Shenandoah 虽标称低停顿，但 Full GC 仍会在极端晋升失败或元空间耗尽时发生
这些“降级路径”都始于 Minor GC 后的晋升行为，而非老年代自发满了才启动。
