不应在生产环境代码中主动调用 system.gc()，因其仅是建议、可能被忽略，易触发高开销 full gc、干扰 jvm 自动内存管理、掩盖真实内存泄漏问题，仅极少数场景可谨慎使用。
不应该在生产环境代码中主动调用 System.gc()。
它不保证触发垃圾回收
System.gc() 只是一个建议，JVM 可以完全忽略该请求。现代 JVM（如 HotSpot）默认启用 -XX:+DisableExplicitGC 时，显式调用会被直接跳过。即使未禁用，也只可能触发一次 Full GC，而 Full GC 开销大、停顿时间长，反而损害稳定性。
干扰 JVM 的自动内存管理策略
JVM 的 GC 策略（如 G1、ZGC、Shenandoah）依赖运行时统计信息动态决策何时回收、回收哪些区域。人为插入 System.gc() 会打乱这些节奏，可能导致：
- 频繁的 Full GC，加剧 STW（Stop-The-World）停顿
- 年轻代对象被提前晋升到老年代，加速老年代耗尽
- GC 日志失真，掩盖真实内存泄漏或配置问题
常被误用为“内存泄漏补救措施”
开发者有时在发现内存占用高时，试图用 System.gc() “清理一下”。这掩盖了根本问题：
- 缓存未设上限或未淘汰（如静态 Map 持有大量对象）
- 监听器/回调未反注册（尤其 GUI 或事件驱动框架）
- 流、连接、线程等资源未正确关闭（间接导致对象无法回收）
真正该做的是用 jstat、jmap、VisualVM 或 Arthas 定位对象存活路径，修复代码逻辑。
极少数例外场景（仍需谨慎）
仅在以下情况可考虑，并必须配合监控和压测验证：
- 长时间运行的批处理任务末尾，且已确认本次任务产生了大量可回收短期对象
- 嵌入式或资源受限环境（如某些 IoT JVM），且明确知道 GC 行为并接受可控停顿
- 单元测试中模拟 GC 行为（但生产代码绝不出现）
即便如此，也应优先通过调整 JVM 参数（如 -XX:MaxGCPauseMillis）或选用低延迟 GC 器来优化，而非手动干预。
不复杂但容易忽略：让 JVM 自己决定什么时候回收，比你替它做决定更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
