System.gc()仅是向JVM发出Full GC建议，不保证执行；其底层经JNI调用JVM_GC()，但受DisableExplicitGC配置、内存压力及GC策略等运行时状态制约。
Java 中可以通过 System.gc() 或 Runtime.getRuntime().gc() 主动建议 JVM 进行垃圾回收，但这仅是建议，JVM 不保证立即执行或执行任何回收操作。
调用方式很简单
两种写法等价，本质都是触发 JVM 的 GC 建议：
System.gc();Runtime.getRuntime().gc();
为什么不能强制执行 GC
JVM 对垃圾回收有自主调度策略，包括：
- 当前堆内存是否真的紧张（比如 Eden 区已满、老年代使用率高）
- 所用的垃圾收集器类型（如 G1、ZGC、Shenandoah 等对显式 GC 的响应不同）
- JVM 启动参数（例如
-XX:+DisableExplicitGC会直接忽略所有System.gc()调用）
某些场景下（如容器环境、低延迟服务），显式 GC 可能被禁用或退化为 NOP（空操作）。
立即学习“Java免费学习笔记（深入）”；
哪些情况可能“看似有效”
在以下简单环境中，System.gc() 更容易观察到效果：
- 使用 Serial 或 Parallel GC 的小型应用
- 手动分配大量临时对象后立刻调用（如循环中创建大数组并置 null）
- 配合
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps查看日志确认是否触发
注意：即使日志显示 “Full GC (System)”，也不代表所有不可达对象都被清理——例如软引用、弱引用对象是否回收，仍取决于 JVM 当前策略和内存压力。
更合理的替代思路
比起依赖 System.gc()，推荐以下实践：
- 避免频繁创建短生命周期大对象，减少 GC 压力
- 及时将不再使用的对象引用设为
null（尤其在长生命周期容器中） - 合理设置堆大小（
-Xms/-Xmx）与 GC 参数，让 JVM 自主高效管理 - 用
java.lang.ref包中的SoftReference、WeakReference控制对象生命周期
主动调用 GC 属于反模式，现代 JVM 已足够智能，过度干预反而影响吞吐与响应时间。
