System.gc()不触发年轻代晋升，但能暴露空间分配担保失败：当老年代剩余空间＜历史晋升均值时，JVM跳过Minor GC直接Full GC。
System.gc() 本身不直接触发年轻代对象晋升，但它能帮你“逼出”晋升失败的场景，从而反向验证分代回收中晋升逻辑是否生效。
晋升不是靠 System.gc() 驱动的，而是靠 Minor GC 和空间压力
年轻代对象晋升到老年代，核心条件是：在一次 Minor GC 后，存活对象需要复制进 Survivor 区或晋升至老年代，但 Survivor 空间不足，或对象年龄达到阈值（默认 15），或对象过大（超过 -XX:PretenureSizeThreshold）——这时 JVM 就会尝试把对象往老年代送。
而 System.gc() 触发的是 Full GC，它会清理整个堆（包括年轻代和老年代）。所以它不会“模拟”晋升过程，但能暴露晋升背后的担保机制是否被打破。
用 System.gc() 验证“空间分配担保”是否失效
JVM 在每次 Minor GC 前会做一次检查：老年代剩余空间是否 ≥ 历次晋升到老年代的平均大小？这个检查叫“空间分配担保”。如果担保失败，JVM 可能跳过 Minor GC，直接 Full GC——这正是你通过 System.gc() 后观察日志能捕捉到的关键信号。
你可以这样设计验证：
- 设置较小的老年代（如 -Xmx128m -XX:NewRatio=1），让老年代容易“吃紧”
- 持续分配中等大小对象（刚好躲过大对象直入老年代），让多次 Minor GC 后不断有对象晋升
- 在某次 Minor GC 前，老年代剩余空间已低于历史晋升均值 → JVM 认为“担保失败”
观察日志里的关键线索
开启 GC 日志（-XX:+PrintGCDetails -Xloggc:gc.log）后，关注这些输出：
- "Promotion failed"：明确表示晋升失败，通常紧跟着 Full GC
- "Ergonomics: … attempting full collection"：说明 JVM 主动降级为 Full GC
- "PSYoungGen" 和 "ParOldGen" 同时回收：确认是 Full GC，而非单独的 Minor GC
注意：如果开启了 -XX:+DisableExplicitGC，System.gc() 就完全无效；如果用了 G1 或 ZGC，显式调用可能只触发并发周期，不等于传统 Full GC。
真正驱动晋升的是对象生命周期和内存压力
想稳定复现晋升行为，比调用 System.gc() 更有效的方式是：
- 分配一批对象填满 Eden，触发 Minor GC，观察哪些进了 Survivor、哪些直接进了老年代
- 反复分配 + GC，让对象年龄增长，看是否在第 15 次 GC 后晋升
- 分配一个超大数组（如 new byte[8_000_000]），并设置 -XX:PretenureSizeThreshold=4194304，观察它是否绕过年轻代直入老年代
System.gc() 的价值，在于它是一个“压力探针”：当它频繁引发 Full GC，往往说明老年代已经没有足够余量承接晋升对象——这才是分代设计中“晋升逻辑正在起作用”的间接证据。
