System.gc() 不会强制执行垃圾回收，仅是向JVM发出建议，可能触发Full GC导致秒级停顿、干扰自适应GC策略并掩盖内存泄漏问题；应禁用并采用资源管理、弱引用等替代方案。
System.gc() 不会强制执行垃圾回收，也没有“立即生效”这回事。它只是向 JVM 发出一个建议，是否响应、何时响应、执行哪类 GC（如 Young GC 还是 Full GC），完全由 JVM 自主决定。所谓“性能开销”，本质不是调用本身耗资源，而是它可能触发的 Full GC 带来的停顿与干扰。
它可能引发秒级 Stop-The-World
多数 HotSpot JVM 默认将 System.gc() 映射为 Full GC 请求。这意味着整个 Java 堆（新生代 + 老年代）被扫描、标记、清理、压缩——所有应用线程必须暂停。一次 Full GC 可能持续数百毫秒到数秒，导致：
- HTTP 接口超时、RPC 调用失败
- 数据库连接池耗尽、事务中断
- 实时音视频帧丢弃、IoT 设备心跳超时
它干扰 JVM 的自适应策略
现代 GC（如 G1、ZGC、Shenandoah）依赖历史分配速率、晋升频率、内存碎片等数据动态调整回收节奏。System.gc() 的突兀介入会：
- 打乱预测模型，使 GC 提前或滞后于真实压力点
- 在低负载时触发冗余回收，浪费 CPU
- 在高负载时因被忽略而掩盖内存泄漏信号
它掩盖真正的内存问题
开发者误以为调用 System.gc() 就等于“释放了内存”，从而忽视根本原因：
- 未关闭 InputStream/Socket 导致文件句柄或连接泄漏
- 静态 Map 持有对象引用，造成对象长期无法回收
- 线程局部变量（ThreadLocal）未 remove，引发内存缓慢增长
替代方案更可控、更安全
想降低内存压力？重点不是“催 GC”，而是切断引用、缩短生命周期：
- 大对象使用后及时置为 null（仅在长生命周期容器中必要）
- 流、连接、锁等资源一律用 try-with-resources 或显式 close
- 缓存场景优先选 WeakReference / SoftReference / Caffeine
- 通过 -XX:+PrintGCDetails 和 JFR 定位真实晋升瓶颈，而非靠 System.gc() “碰运气”
线上环境应默认禁用显式 GC：启动参数加上 -XX:+DisableExplicitGC，可彻底屏蔽第三方库或遗留代码中的非法调用。真正需要内存腾挪的场景（如微服务滚动下线前），也应通过运维流程控制，而非代码中埋点。
