system.gc() 在 jvm 内存调优中基本没有必要，也不应作为常规手段，它只是建议而非指令，jvm 可忽略，可能触发不可控的 full gc，掩盖内存泄漏等根本问题，生产环境应禁用并优先采用引用管理、监控分析等可持续方案。
System.gc() 在 JVM 内存调优中基本没有必要，也不应作为常规调优手段。它既不解决根本内存问题，反而容易引发性能波动和行为不可控。现代 JVM 的自动垃圾回收机制远比人工干预更可靠、更高效。
System.gc() 本质是建议，不是指令
调用 System.gc() 只是向 JVM 发出一个“可以考虑回收”的信号，JVM 完全有权忽略。是否执行、何时执行、执行哪种 GC（Minor 或 Full），全部由 JVM 根据当前内存压力、GC 策略、运行负载等内部状态决定。你无法控制，也无法预测。
- HotSpot 默认响应，可能触发 Full GC；Zing 或某些嵌入式 JVM 则直接忽略
- 即使触发，也未必释放预期内存——比如对象仍被强引用，或堆外内存未关联到 GC 周期
- 在高并发或低延迟场景下，一次 Full GC 可能导致数百毫秒甚至秒级 STW，业务直接受损
它掩盖问题，而非解决问题
开发者看到内存占用升高，第一反应调用 System.gc()，看似“清了内存”，实则跳过了真正该查的环节：对象是否泄漏？缓存是否没设上限？大对象生命周期是否过长？弱引用/软引用是否用错？
- 频繁调用 System.gc() 往往是内存设计缺陷的“止痛药”，延缓根因定位
- 尤其在 DirectByteBuffer 场景下，堆外内存不会因 System.gc() 自动释放——Cleaner 依赖的是对象被 GC 回收，而 GC 是否发生、何时发生，System.gc() 并不能保证
- 误以为“调了就安全”，反而放松对引用管理、资源关闭、池化策略的关注
生产环境应默认禁用
绝大多数生产系统都应在启动参数中加入 -XX:+DisableExplicitGC。这能有效拦截代码、第三方库甚至 RMI 自动发起的显式 GC 请求，避免意外干扰。
- 禁用后，JVM 仍会按需自主触发 GC，且策略更稳定、更可预测
- 若需验证某段逻辑后的内存状态（如压测后对比），可在测试环境临时启用，并配合 GC 日志（-Xlog:gc*:file=gc.log）确认是否真有回收发生
- 微服务滚动清理等极少数运维场景，应通过 JMX 远程触发，并严格限定在低峰期、单节点、有回滚预案的前提下操作
真正有效的替代方案
与其纠结要不要调 System.gc()，不如把精力放在更可控、更可持续的内存实践上：
- 及时解引用：大集合、缓存、监听器等使用完毕后主动 clear() 或置 null
- 善用引用类型：缓存用 WeakHashMap / SoftReference；避免长期持有强引用
- 分治与复用：拆分超大对象；用对象池（如 Netty 的 PooledByteBufAllocator）减少分配压力
- 监控先行：开启 GC 日志 + 使用 GCViewer 或 GCeasy 分析回收频率、停顿、晋升率，定位瓶颈代
