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）采用并发标记与重定位，无法按需“立刻停顿回收”
