system.gc()仅是向jvm发出执行full gc的建议，不保证触发、时机或类型；其底层经jni调用jvm_gc()入口，但是否执行取决于disableexplicitgc配置及内存压力等运行时状态。
System.gc() 不是直接执行垃圾回收的命令，而是向 JVM 发出一个“建议”——请求尽快执行一次 Full GC。它的底层调用链清晰、轻量，但实际是否触发、何时触发、以何种方式触发，完全由 JVM 决定。
调用链：从 Java 方法到底层 C++ 实现
整个过程是一条标准的 JNI 调用路径：
-
Java 层：调用
System.gc()，内部直接委托给Runtime.getRuntime().gc() -
JNI 层：
Runtime.gc()是 native 方法，对应 JVM 中的Java_java_lang_Runtime_gc函数（定义在Runtime.c） -
JVM 层：该函数调用
JVM_GC()（位于jvm.cpp），这是 GC 的统一入口 -
堆实现层：
JVM_GC()检查DisableExplicitGC参数，若未禁用，则调用当前堆对象（如G1CollectedHeap或ParallelScavengeHeap）的collect()方法，并传入原因_java_lang_system_gc
是否真的触发 GC？取决于 JVM 配置和运行状态
关键点在于：这个调用不保证任何行为发生。JVM 可能立即响应，也可能完全忽略：
- 如果启动时加了
-XX:+DisableExplicitGC，JVM_GC()就变成空函数，什么也不做 - 即使未禁用，JVM 仍可能因内存充足、GC 线程繁忙或策略限制而延迟甚至跳过这次请求
- 不同 GC 算法处理方式不同：G1 和 ZGC 在收到
_java_lang_system_gc时倾向于触发一次混合收集或并发标记周期；而 CMS 已被弃用，Shenandoah 则更激进地尝试低停顿响应
它触发的是哪种 GC？通常是 Full GC，但不绝对
传统理解中，System.gc() 触发的是对整个堆（新生代 + 老年代）的回收，即 Full GC。但现代 JVM 更倾向按需响应：
- 使用 G1 时，它可能触发一次 Mixed GC（清理部分老年代 + 所有新生代），而非全堆 Stop-The-World
- ZGC 和 Shenandoah 在绝大多数场景下不会因
System.gc()进入 STW 阶段，而是加速其已有的并发 GC 周期 - 真正执行 Full GC 的典型场景，反而多见于 Parallel GC 或未配置现代收集器的老系统
为什么设计成“建议式”而非“强制式”？
这是 JVM 自动内存管理哲学的核心体现：
- 手动干预容易破坏 JVM 的自适应 GC 策略（如分代假设、内存增长预测、暂停时间目标）
- 频繁调用会干扰 GC 线程调度，增加 CPU 开销，甚至引发 GC 飙升（GC Thrashing）
- 现代 JVM 对堆外内存、引用队列、Cleaner 机制的管理，已不再依赖显式 Full GC 来释放资源
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
