System.gc()仅是向JVM发出非强制GC建议，是否执行及执行类型由JVM自主决定；现代JDK常忽略该调用，频繁使用反而干扰GC节奏，仅在NIO堆外内存失败、批处理结束或单元测试等特定场景下作为尽力提示使用。
Java 中 System.gc() 不能真正“强制”触发垃圾回收，它只是向 JVM 发出一个建议，是否执行、何时执行、执行多彻底，完全由 JVM 决定。但在特定测试场景（比如验证对象是否被正确释放、模拟内存压力、排查资源泄漏）中，可以结合它与其他手段来提高触发概率和可观测性。
明确目的：不是强制，而是“提示 + 配合”
调用 System.gc() 本身不保证 GC 发生。JVM（尤其是 G1、ZGC 等现代收集器）可能忽略该调用，尤其在低负载或配置了 -XX:+DisableExplicitGC 时。因此，测试中需配合以下操作提升效果：
- 确保没有强引用残留（如静态集合、缓存、监听器未清理）
- 主动将待回收对象置为
null，并让局部变量作用域结束 - 配合
Runtime.getRuntime().runFinalization()（对已标记但未执行 finalize 的对象补发终结） - 使用
-XX:+PrintGCDetails -XX:+PrintGCDateStamps观察日志确认是否真发生了 GC
典型测试场景下的实用写法
例如验证某类资源（如自定义 Closeable 对象）是否在无引用后被回收：
// 创建对象并显式释放（若支持）
MyResource resource = new MyResource();
resource.close(); // 主动释放关键资源
<p>// 切断引用
resource = null;</p><p>// 建议 GC，并等待短暂时间（非阻塞，仅提高观察几率）
System.gc();
try { Thread.sleep(10); } catch (InterruptedException e) { }</p><p>// 可选：再触发一次 finalization（仅适用于仍使用 finalize 的老代码）
Runtime.getRuntime().runFinalization();</p><p>// 检查弱引用/虚引用是否被入队，或通过 JVMTI/Instrumentation 验证对象是否已不可达
更可靠替代方案：避免依赖 System.gc()
在自动化测试中，过度依赖 System.gc() 会导致结果不稳定。推荐以下更可控方式：
立即学习“Java免费学习笔记（深入）”；
-
使用弱引用/虚引用监听回收：创建
PhantomReference关联ReferenceQueue，当对象被回收时队列会收到通知 -
借助 JVM TI 或 JFR 事件：通过 Java Flight Recorder 记录
GarbageCollection事件，程序中查询是否发生指定类型 GC -
人为制造内存压力：分配大数组（如
new byte[1024 * 1024 * 50]），迫使 JVM 触发 GC（比System.gc()更可靠） - 单元测试中用 mock 替代资源管理：验证 close() 是否被调用，而非等 GC —— 更快、更确定
注意事项与常见陷阱
直接在生产代码中调用 System.gc() 是反模式；测试中也需谨慎：
- 某些容器（如 Docker）或云环境会限制 JVM 的 GC 行为，
System.gc()更易失效 - JDK 9+ 中
finalize()已废弃，runFinalization()效果大幅减弱，不应作为主要验证手段 - 频繁调用
System.gc()可能干扰 JVM 的 GC 调优策略，导致测试失真 - JUnit 5 的
@AfterEach中调用无法保证 GC 在断言前完成，建议改用异步监听或重试机制
