System.gc() 默认建议触发 Full GC，但JVM可忽略或降级为Minor GC；其行为因GC算法而异，且不可靠，不应依赖它进行资源清理。
System.gc() 默认触发的是 Full GC，即同时回收新生代、老年代，通常还包括元空间（取决于具体垃圾收集器实现）。但它不是强制命令，而是一次“建议”，JVM 可以忽略，也可以延迟执行，甚至按自身策略降级为 Minor GC 或跳过。
触发的是 Full GC，但不保证立即执行
调用 System.gc() 后，JVM 会尝试启动一次全局范围的垃圾收集。主流 HotSpot JVM（如 G1、Parallel、CMS）在默认配置下，会将其视为 Full GC 请求，回收整个 Java 堆（新生代 + 老年代）及部分元空间内容。不过：
- 该调用没有同步语义，不会阻塞当前线程直到 GC 完成；
- JVM 实现可自行决定是否响应，例如某些嵌入式或裁剪版 JVM 可能直接忽略；
- 若此时堆内存充足、GC 压力低，JVM 可能推迟执行，甚至完全跳过；
- 添加 -XX:+ExplicitGCInvokesConcurrent 参数后，G1 或 ZGC 等并发收集器会将 System.gc() 转为并发标记启动，不再停顿式 Full GC。
不同垃圾收集器的实际行为差异
System.gc() 的最终效果受所选 GC 算法影响较大：
- Parallel GC（吞吐量优先）：默认响应为 Stop-The-World 式 Full GC，暂停时间明显；
- G1 GC：默认仍走 Full GC 流程，但可通过 -XX:+ExplicitGCInvokesConcurrent 改为并发标记起点，降低停顿；
- ZGC / Shenandoah：基本无视 System.gc()，即使调用也仅触发一次轻量级回收尝试，不中断应用线程；
- Serial GC：严格按 Full GC 执行，单线程扫描全堆，停顿最久。
为什么不能依赖它做资源清理
System.gc() 不是资源管理的可靠手段，原因包括：
- finalize() 方法已被弃用（Java 9 起标记为 deprecated，Java 18 彻底移除），无法靠它保障清理逻辑；
- 对象是否被回收，取决于可达性分析结果，而非是否调用了 System.gc()；
- 频繁调用反而干扰 JVM 的自适应 GC 调度，可能引发 GC 飙升、吞吐下降；
- 真实业务中，应使用 try-with-resources、Cleaner、虚引用配合 ReferenceQueue 等现代替代方案。
验证方式与调试建议
要确认 System.gc() 是否生效及类型，需结合 JVM 参数观察日志：
- 启用详细 GC 日志：-XX:+PrintGCDetails -Xloggc:gc.log；
- 区分 GC 类型：日志中出现 “Full GC” 或 “Pause Full” 表示触发了 Full GC；出现 “GC pause (G1 Evacuation Pause)” 则说明被 G1 降级处理；
- 注意时间戳和停顿时间字段（如 “user=0.02s, sys=0.00s, real=0.03s”），可判断是否真正发生了 Stop-The-World；
- 避免在生产环境无监控地调用，建议仅用于基准测试或诊断场景。
