JVM垃圾回收由内存空间压力触发：Eden区满触发Minor GC，老年代不足时触发Major GC或Full GC，本质是分配失败后的被动响应，而非定时执行。
JVM 垃圾回收不是定时闹钟，也不是随心所欲的清扫工，它由具体内存状态和运行策略驱动。触发与否，取决于“有没有地方放新对象”以及“系统是否允许此时清理”。关键不在于时间，而在于空间压力与回收成本之间的权衡。
内存空间不足是核心触发器
GC 最本质的动因是分配失败：当 JVM 尝试给新对象分配内存，却发现对应区域没有足够连续空间时，就会启动回收流程。这不是预测性行为，而是被动响应。
- 新生代填满 Eden 区 → 触发 Minor GC：这是最常见、最频繁的触发场景。Eden 区通常较小（几十 MB 级），大量短生命周期对象快速占满后，必须清理才能继续分配。
- 老年代剩余空间不足以接收晋升对象 → 触发 Major GC 或 Full GC：比如一次 Minor GC 后，存活对象太多、体积太大，需要进入老年代，但老年代已快耗尽，此时必须先清理老年代。
- 堆总内存达到 -Xmx 上限且无法扩容 → 多次 GC 仍失败 → 抛出 OutOfMemoryError：说明回收已跟不上分配节奏，不是没触发，而是触发了也救不回来。
JVM 参数设定直接影响触发节奏
参数不直接“命令 GC 执行”，而是划定内存边界和行为规则，间接决定 GC 频率与强度。
- -Xms 和 -Xmx：设定了堆的初始与最大容量。两者差距大（如 -Xms2g -Xmx8g）会导致堆动态扩容，扩容前若空间紧张可能提前触发 GC；两者相等（如 -Xms4g -Xmx4g）则堆固定，GC 更依赖实际使用水位。
- -Xmn：明确新生代大小。新生代越小，Eden 区越容易满，Minor GC 越频繁；过大则可能让短命对象滞留过久，增加老年代压力。
- -XX:MaxTenuringThreshold：控制对象在新生代“熬”多少轮才晋升。阈值设低（如 3），对象更快进老年代，可能加剧老年代压力；设高（默认 15），则延长新生代驻留，降低老年代负担但需更多 Survivor 空间。
主动请求不可靠，仅作提示
调用 System.gc() 或 Runtime.getRuntime().gc() 只是向 JVM 发出一个建议，不是指令。JVM 会结合当前 GC 状态、线程负载、回收收益预估等综合判断是否执行。
- 在 CMS 或 G1 等并发收集器中，该调用常被忽略，避免打断并发标记过程。
- 即使触发，也未必是 Full GC —— 可能只做一次 Minor GC，或干脆跳过。
- 频繁调用反而干扰 JVM 自身的 GC 调度策略，可能导致 STW 时间分布异常或吞吐量下降。
回收能力受限于算法与堆结构
即使触发了 GC，能否有效释放空间，还受制于当前使用的垃圾回收器及其内在机制。
- 标记-清除算法：易产生内存碎片。即使总空闲空间充足，也可能因缺乏连续大块而无法分配大对象，进而反复触发 GC。
- 复制算法（如新生代）：依赖 From/To 区切换，若 Survivor 区太小，存活对象无法全部容纳，就会直接“担保失败”晋升老年代，加重老年代压力。
- 元空间（Metaspace）不足：加载大量类（如热部署、反射生成类）导致元空间耗尽，也会触发 Full GC，甚至抛出 java.lang.OutOfMemoryError: Metaspace。
