system.gc() 是潜在性能干扰源，会引发秒级停顿、强制安全点、易触发 full gc、破坏 gc 器自适应调度，并掩盖真实内存问题；应禁用而非评估，推荐启用 -xx:+disableexplicitgc。
System.gc() 不是性能优化手段，而是潜在的性能干扰源。它不加快回收，反而可能引发秒级停顿、拖慢所有线程、打乱 JVM 自适应 GC 节奏。
它会强制进入安全点，拖慢整个应用
每次调用 System.gc()，JVM 必须让所有应用线程暂停并进入安全点（Safepoint），才能开始任何回收动作。这个等待过程本身就有开销：
- 正在执行长循环、正则匹配或 native 方法的线程需先完成当前操作
- 高并发下多个线程争抢安全点入口，造成明显延迟
- 即使最终没触发 GC，同步开销已发生，白白消耗 CPU 和响应时间
它容易触发 Full GC，带来不可控 STW
HotSpot 默认将 System.gc() 解释为 Full GC 请求，哪怕老年代只用了 15%。结果就是：
- 接口 P99 延迟突然跳涨 1–3 秒
- Kubernetes liveness probe 连续失败，Pod 被反复驱逐
- RMI 或定时任务每小时卡顿一次（RMI 内置默认调用）
- GC 日志中频繁出现 Full GC (System.gc())，但堆内存其实很空
它干扰现代 GC 器的智能调度
G1、ZGC、Shenandoah 等收集器依赖运行时统计做预测性回收。System.gc() 的突兀请求会破坏这种节奏：
- G1 可能提前启动混合回收，打乱区域清理优先级
- ZGC 虽忽略显式调用，但频繁 hint 仍增加内部状态判断负担
- 回收器被迫放弃自适应策略，转而处理非最优时机的回收请求
它掩盖真实内存问题，延误根因定位
开发者看到调用后内存下降，就误以为“起效了”，实则掩盖了真正的问题：
- 静态 Map 缓存大对象 → 引用未清，System.gc() 根本无效
- InputStream/Socket/Channel 未用 try-with-resources 关闭 → finalize 滞后，对象长期滞留
- DirectByteBuffer 分配后未 clean → 堆外内存持续泄漏，System.gc() 完全无感
- ThreadLocal 变量未 remove → 线程池复用下缓慢堆积
禁用比评估更实际、更优先
与其花时间“评估开销”，不如直接屏蔽显式调用：
- 启动参数加 -XX:+DisableExplicitGC，让所有 System.gc() 静默返回
- 配合 -XX:+PrintGCDetails 观察日志，确认不再出现 “(System.gc())” 记录
- 用 jstat -gc
检查 FGC 列是否停止非预期增长
真正该盯住的，从来不是“要不要 GC”，而是“为什么还有引用挂着”、“哪些资源该关没关”、“对象生命周期是否失控”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
