System.gc()不能保证立即触发垃圾回收，因为它只是向JVM发出的礼貌性建议而非执行指令，是否响应、何时响应及以何种方式响应（Minor/Mixed/Full GC）均由JVM根据堆状态、GC策略、安全点机制及参数（如-XX:+DisableExplicitGC）自主决定。
System.gc() 不能保证立即执行 GC，因为它根本就不是一条“执行指令”，而只是一个礼貌性的建议——就像你对室友说“这屋该扫扫了”，对方听没听见、听懂没听懂、什么时候扫、怎么扫，全由对方自己决定。
它本质是提示，不是命令
Java 规范明确写明：System.gc() 的作用是“向 JVM 提示现在可能适合进行垃圾回收”。JVM 不会因此立刻调度 GC 线程，也不会阻塞当前线程等待回收完成。它只是触发一个内部信号，后续是否响应、何时响应、以何种方式响应（Minor、Mixed 还是 Full GC），完全由 JVM 自主判断。
- HotSpot 中，它最终调用的是 CollectedHeap::collect 的间接入口，不带同步语义，也不返回任何结果
- 字节码里只生成一条 invokestatic 指令，没有锁、没有等待、没有确认机制
- 调用后方法立即返回，无论 GC 是否发生、何时发生
安全点（Safepoint）机制强制延迟
GC 必须等所有 Java 线程都到达安全点才能开始。如果某个线程正卡在以下位置，整个 GC 就会被拖住：
- 执行长耗时 JNI 方法（比如图像解码、加密计算）
- 进行偏向锁批量撤销（尤其在启用 -XX:+UseBiasedLocking 时）
- 调用底层未插入轮询点的 System.arraycopy 或大数组拷贝
这种情况下，System.gc() 调用后可能等数秒甚至几十秒才真正启动 GC，日志里会显示明显的 STW 延迟。
立即学习“Java免费学习笔记（深入）”；
不同 GC 策略响应差异极大
JVM 并不统一处理这个请求，而是按收集器“各自为政”：
- G1 默认映射为 Full GC 请求，但可通过 -XX:+ExplicitGCInvokesConcurrent 改为并发模式
- ZGC / Shenandoah 完全无视 System.gc()，既不响应也不阻塞
- Parallel GC 通常会响应，但仍需排队等待 GC 线程调度
- 若启动参数含 -XX:+DisableExplicitGC，调用直接变成空操作（NOP）
它还可能带来实际危害
盲目依赖或频繁调用，反而容易引发问题：
- HotSpot 默认将显式请求转为 Full GC，导致秒级 Stop-The-World，影响接口超时、连接池枯竭
- 打乱 G1/ZGC 的自适应预测模型，造成回收节奏失准
- 掩盖真实内存泄漏——比如静态 Map 持有对象、监听器未注销、流未关闭
- 对堆外内存（如 DirectByteBuffer）完全无效，白调也白调
