System.gc()仅是向JVM发出垃圾回收建议，不保证立即或执行GC，因JVM可忽略、延迟、合并或跳过该请求，且受GC策略、堆压力、参数（如-XX:+DisableExplicitGC）等多重因素制约。
调用 System.gc() 只是向 JVM 发出一个**建议**，请求它尽快执行一次垃圾回收（GC），但 JVM 完全可以忽略该请求，不保证立即或一定会执行 GC。
为什么 System.gc() 不可靠
JVM 的垃圾回收策略由具体实现（如 HotSpot）和运行时参数（如使用的 GC 算法、堆内存压力、是否开启显式 GC 禁用等）共同决定。现代 JVM 通常更依赖自动化的内存管理机制，而非外部干预。
- 在 OpenJDK / HotSpot 中，可通过
-XX:+DisableExplicitGC参数彻底禁用System.gc()（此时调用无效） - 即使未禁用，JVM 也可能延迟、合并或跳过此次请求，尤其在 GC 压力不大时
- 频繁调用反而可能干扰 GC 的自适应节奏，导致性能下降
什么情况下可谨慎考虑使用
仅限于极少数明确需要“尽力释放内存”的场景，且已充分评估副作用：
- 长时间运行的模块结束前（如某大型数据处理任务完成），希望主动释放大对象引用链
- Android 应用中某些低内存回调后，作为辅助手段尝试回收（但仍需配合 proper object nulling）
- 单元测试中验证资源清理逻辑（非生产环境）
更推荐的替代做法
依赖 JVM 自动管理，同时从代码层面减少 GC 压力：
- 及时将不再使用的长生命周期引用设为
null（尤其静态集合、缓存、监听器） - 使用
try-with-resources确保AutoCloseable资源释放 - 避免在循环中创建大量临时对象；复用对象（如
StringBuilder）、使用对象池（谨慎评估收益） - 通过 JVM 参数优化 GC 行为，例如调整堆大小（
-Xms/-Xmx）、选择合适 GC 算法（-XX:+UseG1GC）
如果仍要调用，注意写法与观察
调用本身很简单，但验证效果需借助工具：
- 写法：
System.gc();（无参数，无返回值） - 观察是否触发：启用 GC 日志（如
-Xlog:gc*:file=gc.log）查看日志中是否有对应 GC 事件 - 不要用
Runtime.getRuntime().gc()—— 它和System.gc()效果完全相同，只是封装一层
