system.gc() 有害无益，它强制安全点同步拖慢线程、干扰现代gc器智能调度、在容器中引发oomkilled、掩盖真实内存泄漏根源。
System.gc() 本身不回收对象，但调用它会带来真实且可观的开销——不是“有没有用”的问题，而是“有没有害”的问题。它常被当作内存紧张时的急救按钮，结果却让系统更卡、更慢、更不稳定。
触发安全点同步，拖慢所有线程
每次调用 System.gc()，JVM 必须让所有应用线程进入安全点（Safepoint）才能开始 GC 操作。这个过程需要等待：
- 正在执行长循环或 native 方法的线程完成当前动作
- 高并发场景下，大量线程争抢安全点入口，造成明显延迟
- 即使最终没触发 Full GC，同步开销已发生，白白消耗 CPU 和响应时间
干扰现代 GC 器的智能调度
G1、ZGC、Shenandoah 等收集器依赖运行时统计做预测性回收。System.gc() 的突兀请求会打乱节奏：
- G1 可能提前启动混合回收，打乱区域清理优先级
- ZGC 虽忽略显式调用，但频繁 hint 仍增加 JVM 内部状态判断负担
- 回收器被迫放弃自适应策略，转而处理非最优时机的回收请求
在容器环境引发误判与连锁故障
云原生环境下，System.gc() 的副作用会被放大：
- cgroup 内存统计可能将 GC 阶段的瞬时峰值误读为持续压力
- Kubernetes 主动触发 OOMKilled，杀掉本可正常运行的 Pod
- 日志中看不到 GC 记录（尤其开启 -XX:+DisableExplicitGC 后），问题难以复现和归因
假缓解真掩盖，让内存问题更难定位
开发者看到调用后内存下降，就以为“起效了”，实则掩盖了根本缺陷：
- 静态 Map 缓存大对象 → 调用 System.gc() 发现没释放 → 误判为 GC 失效，忽略引用未清
- DirectByteBuffer 未 clean → 堆外内存持续增长 → 错把元空间或 native OOM 当作堆溢出
- Finalizer 队列积压 → Full GC 触发后 finalizer 线程跟不上 → 对象卡在老年代，直接 OOM
真正影响性能的，从来不是“GC 没发生”，而是“不该存在的引用还挂着”、“资源该关没关”、“对象生命周期失控”。System.gc() 不解决任何一项，只增加一层干扰。
