不会。System.gc() 仅向 JVM 发出垃圾回收建议，不保证立即执行或触发 Full GC，实际行为取决于 GC 策略、堆状态和运行时负载，频繁调用反而干扰 GC 自适应策略。
System.gc() 真的会立刻回收垃圾吗
不会。调用 System.gc() 只是向 JVM 发出一个“建议”，JVM 可以完全忽略它，也可以延迟执行，甚至在某些 GC 策略下（比如 G1 或 ZGC）直接跳过。它的实际效果取决于当前使用的垃圾收集器、JVM 参数、堆状态和运行时负载。
常见错误现象：System.gc() 调用后内存没降、Runtime.getRuntime().freeMemory() 值几乎不变、VisualVM 中看不到对应 GC 事件。
- 它不保证触发 Full GC，HotSpot 默认只建议触发一次全局 GC，但具体行为由 VM 决定
- 在容器环境（如 Docker）中，若未正确配置内存限制（
-XX:MaxRAMPercentage），System.gc()可能更易被忽略 - 频繁调用反而干扰 GC 自适应策略，导致吞吐量下降
哪些场景下还可能用到 System.gc()
极少，但不是完全没用——关键看是否处于「可控、短暂、可预测」的生命周期边界。
典型可用场景：
- 嵌入式或资源极度受限的 Java 应用（如 Java ME 风格设备），且已禁用后台 GC 线程
- JNI 调用释放了大量本地内存后，希望尽快腾出 Java 堆空间供后续复用
- 单元测试中模拟内存压力（仅限测试代码，生产禁用）：比如在
@After中清理大对象图，避免影响下一个测试
注意：System.gc() 在 Web 应用、Spring Boot 服务、批处理任务中基本没有正当理由使用。
替代 System.gc() 的更可靠做法
真正需要控制内存节奏时，靠“触发 GC”不如靠“减少 GC 需求”或“显式管理对象生命周期”。
- 用
try-with-resources确保AutoCloseable资源及时释放（如ByteBuffer、MappedByteBuffer） - 对缓存类对象，优先用
WeakReference或SoftReference，配合ReferenceQueue主动清理 - 大数组或图像数据，考虑复用
byte[]或使用堆外内存（ByteBuffer.allocateDirect()），并手动调用cleaner.clean()（需反射或Unsafe） - 通过 JVM 参数主动干预 GC 行为，比如
-XX:+UseG1GC -XX:MaxGCPauseMillis=50，比写System.gc()更有效
如何验证 System.gc() 是否起了作用
不能只看内存数字变化。得结合 GC 日志和时间戳交叉判断。
启用 GC 日志（推荐 JDK 9+ 格式）：
-Xlog:gc*:gc.log:time,tags,level
然后在代码中这样夹击验证：
long t1 = System.nanoTime(); System.gc(); long t2 = System.nanoTime(); // 查 gc.log 中 [t1, t2] 区间内是否有 GC（特别是 Pause Full）事件
容易踩的坑：
- 用
Runtime.getRuntime().totalMemory()/freeMemory()判断效果——这两个值反映的是 JVM 向 OS 申请的内存池大小，不是实时存活对象量 - 在 JMH 基准测试里调用
System.gc()——JMH 默认已禁用它，且会报 warning - 依赖 IDE 控制台输出确认 GC，而没开 GC 日志——很多 GC 是 silent 的
真正难的不是调不调 System.gc()，而是怎么让对象早死、少活、不死在错误的地方。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
