System.gc()不是强制回收指令，仅是向JVM发出垃圾回收建议，实际是否执行、何时执行及执行何种GC均由JVM自主决定；真正决定对象回收的是引用可达性，而非调用该方法。
System.gc() 不是性能优化手段，而是潜在的性能破坏者。它无法强制回收内存，也不能加速对象释放，反而常因触发 Full GC 引发停顿、掩盖真实内存问题、干扰现代收集器的自适应节奏。
它根本不是“强制”，只是个建议
Java 规范明确定义 System.gc() 语义为“向 JVM 发出一次垃圾回收建议”，而非指令。JVM 可选择：
- 直接忽略（尤其开启 -XX:+DisableExplicitGC 时）
- 延迟数秒甚至更久才响应
- 只执行轻量 Young GC，对大数组或老年代对象毫无作用
- 在 Serial/Parallel 等老收集器下误触 Full GC，导致全局停顿
真正决定回收的，从来不是这个调用
对象能否被回收，只取决于两点：是否还存在从 GC Roots 出发的强引用链，以及该对象是否已不可达。例如：
- byte[] buffer = new byte[50MB]; buffer = null; —— 断引用才是关键，System.gc() 后不加这句，对象绝不会被回收
- 局部变量在方法返回后栈帧自动销毁，引用自然消失；此时调用 System.gc() 不加快任何事，只多一次无谓请求
- 若对象被静态 Map、ThreadLocal 或未关闭的 FileInputStream 持有，调一千次 System.gc() 也无效
线上环境调用等于埋雷
生产系统中显式触发 GC 是明确禁止的行为，原因很实际：
- Full GC 可能造成数百毫秒至数秒 STW，HTTP 请求超时、数据库连接中断、定时任务丢帧
- G1/ZGC 等收集器依赖历史行为建模，频繁显式 GC 会扭曲晋升预测、加剧碎片、降低并发效率
- 用 System.gc() “顶替” close() 或 clear()，会掩盖资源泄漏——比如文件句柄耗尽、连接池打满
- 不同 JVM 行为不一致：Zing 忽略该调用，OpenJ9 默认仅并发执行，行为不可移植
比“催 GC”有用得多的做法
想让大对象更快释放？重心应放在引用生命周期控制上：
- 大对象引用在长生命周期容器中更新时，显式置为 null（如缓存淘汰旧值）
- 流、连接、通道等必须用 try-with-resources 确保退出即释放，不依赖 finalize
- 避免静态集合无限制堆积；改用 WeakHashMap 或定期清理策略
- 通过 -XX:+PrintGCDetails 和 JFR 分析真实晋升路径与回收时机，定位内存压力源头
- JVM 启动时加上 -XX:+DisableExplicitGC，从根上拦截第三方库的非法调用
