不会。System.gc() 仅是向 JVM 发出建议，是否执行、何时执行及执行何种回收均由 JVM 自主决定，现代 JDK 默认 GC（如 G1/ZGC）通常忽略或降级处理，甚至可被 -XX:+DisableExplicitGC 禁用。
System.gc() 会立即触发 Full GC 吗？
不会。System.gc() 只是向 JVM 发出一个“建议”，是否执行、何时执行、执行哪种回收（如仅 Young GC 或 Full GC），完全由 JVM 自主决定。现代 JDK（如 JDK 9+）默认启用 G1 或 ZGC，它们对 System.gc() 的响应通常被忽略或降级为轻量级回收，甚至可通过 -XX:+DisableExplicitGC 彻底禁用。
哪些场景下调用 System.gc() 可能“看似有效”？
仅在极少数可控的、非生产环境的边界场景中，有人观察到内存下降，比如：
- 嵌入式或资源极度受限的容器中，且使用 Serial 或 Parallel GC（老版本 JDK）
- 单元测试中手动清理大对象图后，希望快速验证引用是否真的被丢弃
- Swing/AWT 应用中显式释放
BufferedImage或Graphics2D资源后（但更应优先调用flush()和置 null）
注意：这些效果不可靠，且在 G1/ZGC/Shenandoah 下基本无效；依赖它等于把 GC 策略交给了不确定的黑盒。
为什么线上服务严禁调用 System.gc()？
它可能引发严重性能抖动：
- 触发意外的 Full GC，导致 STW 时间飙升（尤其在堆大、老年代碎片多时）
- 干扰 JVM 的自适应 GC 调度（如 G1 的预测模型、ZGC 的并发节奏）
- 在高并发服务中形成“GC 雪崩”——多个线程同时调用，反复触发回收，吞吐骤降
- 日志中出现
Full GC (System.gc())是运维重点排查项，不是正常行为
如果你看到代码里有 System.gc()，第一反应不应该是“怎么让它生效”，而是“为什么这里需要它”——大概率说明对象生命周期管理或缓存设计出了问题。
替代 System.gc() 的实际做法有哪些？
真正释放内存，靠的是让对象不可达 + JVM 自动回收，而非人工催促：
- 及时将长生命周期容器（如
static Map、缓存）中的无用条目remove()或清空 - 避免静态集合持有 Activity/Context（Android）或 ServletRequest（Java EE）等短命对象
- 用
WeakReference/SoftReference管理可回收缓存，而不是靠System.gc()强制回收 - 大文件流、NIO
ByteBuffer、数据库连接等，必须显式close()或clean()，它们的内存不在堆上，System.gc()根本管不了
GC 是结果，不是手段；内存泄漏的根因永远在线上对象引用链里，不在要不要调用 System.gc() 这个开关上。
