System.gc和JVM垃圾回收触发机制的底层交互

System.gc()仅向JVM发出“建议执行GC”的提示，不保证触发任何GC类型或时机；现代JDK（如17+ G1、21+ ZGC）常忽略该调用，真正回收由内存压力与GC策略自主决定。

System.gc() 不触发回收，只发出建议。它既不决定 GC 类型，也不控制执行时机，更不改变对象存活判定逻辑。JVM 是否真正执行回收、执行哪一类 GC（Minor、Mixed 还是 Full），完全由当前内存压力、GC 策略（如 G1、ZGC）、运行时统计信息等内部机制决定。

它到底做了什么？

调用 System.gc() 实际上等价于调用 Runtime.getRuntime().gc()，底层向 JVM 发起一次“建议执行 Full GC”的信号。但现代 JVM（如 JDK 17+ 默认 G1、JDK 21+ ZGC）通常忽略该请求——G1 在多数场景下会直接丢弃该建议；ZGC 和 Shenandoah 甚至不支持同步 Full GC，自然不予响应。

• 不是命令，而是提示（hint），类似“现在可能适合清理一下”
• 是否响应、何时响应、以何种方式响应，全由 JVM 自主决策
• 即使响应，也未必是 Full GC：某些配置下（如开启 -XX:+ExplicitGCInvokesConcurrent），System.gc() 可能只触发并发标记阶段

弱引用回收与 System.gc() 没有因果关系

弱引用对象被回收的唯一条件是：在某次实际发生的 GC 过程中，该对象不可达（即仅被 WeakReference 持有，且无强/软引用路径）。这和有没有调用 System.gc() 无关。

• 没调用 System.gc()，JVM 照样会在 Eden 区满时触发 Minor GC，顺便回收弱引用对象
• 调用了 System.gc()，但 JVM 没执行 GC（比如堆内存充足、G1 判定无需回收），弱引用对象就继续存活
• 哪怕执行了 GC，若对象还被其他引用类型持有，WeakReference.get() 仍返回非 null

如何观察真实 GC 行为？

依赖 System.gc() 做实验容易误判。可靠做法是结合日志与代码控制：

• 加 JVM 参数：-XX:+PrintGCDetails -Xlog:gc*:stdout:time
• 确保目标对象已断开所有强引用（如将引用变量设为 null）
• 用 weakRef.get() 轮询检测，而非 sleep 等待（GC 是异步事件）
• 配合 ReferenceQueue 可监听弱引用入队时机，比轮询更及时准确

为什么设计成“建议”而非“指令”？

强制 GC 会破坏 JVM 的自适应调度能力。例如：

• 在高负载时段强行 Full GC，可能导致 STW 时间激增，服务超时
• 频繁调用会干扰分代假设，降低复制算法效率
• 现代 GC（如 ZGC）采用并发标记与重定位，无法按需“立刻停顿回收”

本质上，System.gc() 是一个遗留接口，保留只为兼容旧代码。生产环境应避免显式调用，让 JVM 自主管理内存生命周期。