Major GC由晋升压力或担保失败被动触发，非老年代填满才执行；核心是“有对象要进但空间不足”，如Minor GC前检查老年代剩余空间不足以容纳待晋升对象，或大对象直接分配失败时触发。
老年代垃圾回收（Major GC）不是靠“老年代填满”才触发，而是由晋升压力或空间担保失败被动引发的。它不主动轮询、也不定时执行，核心是“有对象要进来，但地方不够了”。
主要触发场景：晋升失败
Minor GC 后，一批存活对象准备从新生代晋升到老年代，但 JVM 检查发现老年代剩余连续空间 小于这批对象总大小，就触发 Major GC 来腾地方。这个检查叫“晋升担保（Promotion Guarantee）”，发生在 Minor GC 开始前。
- 哪怕老年代只用了 70%，只要剩余空闲空间不连续或太小，仍可能担保失败
- 大对象（如超长数组）跳过新生代直接分配，若老年代无法容纳，也会触发 Major GC
- 某些收集器（如 CMS）在并发标记未完成时老年代就耗尽，会退化为 Serial Old 单线程回收——这也算 Major GC
其他可能路径
不是所有 JVM 都支持纯老年代回收，但以下情况可能单独清理老年代：
- CMS 收集器运行中出现 Concurrent Mode Failure（并发模式失败）
- Parallel Old 收集器在特定配置下可跳过 Minor GC，直接启动老年代回收
- 显式调用 System.gc() 且未禁用（-XX:+DisableExplicitGC），JVM 可能选择只回收老年代
注意几个常见误解
“Major GC”不是 JVM 规范术语，不同日志或工具含义可能不一致：
- 日志里只标 Old、没 Young 和 Metaspace 动作，才是较可靠的 Major GC
- 很多团队把 Full GC 叫成 Major GC，实际它回收的是整堆+元空间
- Survivor 区满、Eden 未满，不会触发任何 GC；老年代“快满”但没到晋升临界点，也不会触发
真正决定是否回收、怎么回收的，是所选垃圾收集器及其参数。比如 G1 会在老年代占用率达 -XX:InitiatingOccupancyPercent 时启动并发标记，ZGC 则基本不出现传统意义上的 Major GC。
