system.gc()仅是向jvm发出的full gc建议，不保证立即执行；是否触发、何时触发及方式取决于gc策略、堆状态和参数（如-xx:+disableexplicitgc），且必须等待所有线程到达安全点后才能开始。
System.gc() 不是立即执行垃圾回收的指令，而是一个向 JVM 发出的“建议”——提醒它考虑执行一次 Full GC。是否真触发、何时触发、以何种方式触发，完全取决于 JVM 当前状态、GC 策略和启动参数，它本身不保证任何行为。
System.gc() 的实际触发逻辑
调用 System.gc() 本质是调用 Runtime.getRuntime().gc()，这是一个 native 方法，最终交由 JVM 内部处理：
- 若 JVM 启动时设置了 -XX:+DisableExplicitGC，该调用会被直接忽略，什么也不做；
- 否则，JVM 会根据当前使用的 GC 算法决定后续动作： • G1 默认执行 Full GC，但可通过 -XX:+ExplicitGCInvokesConcurrent 改为并发模式（即不 STW 的 Young GC 或 Mixed GC）； • ZGC 完全无视 System.gc()，不响应也不阻塞； • Shenandoah 行为类似 G1，支持显式 GC 并可配置是否并发；
- 即使允许触发，也需等待 GC 线程获得调度权，不是“马上执行”，而是“尽快安排”。
为什么 System.gc() 必须等安全点（Safepoint）？
GC 要准确识别哪些对象还“活着”，就必须确保对象引用关系在某一刻是稳定的。如果用户线程正在修改引用（比如刚把某个对象赋值给字段，还没写完），而 GC 此时扫描堆，就可能漏掉这个新引用，误判为垃圾。
安全点就是 JVM 预设的、线程可以安全暂停的位置。只有当所有用户线程都到达最近的安全点并挂起后，GC 才能开始标记阶段。
- 安全点通常出现在方法调用返回、循环跳转、异常抛出、线程状态切换等指令附近——这些位置天然具备“长时间执行”或“状态可检查”的特征；
- 线程不会被强制中断，而是轮询一个全局标志位（如 is_gc_active），一旦发现为 true，就主动停在下一个安全点；
- 这意味着 System.gc() 触发后，JVM 实际要等到所有活跃线程都“自愿停下”才能真正开始 GC 工作，这会造成不可控的延迟。
安全区域（Safe Region）作为安全点的补充
有些线程可能长时间不执行任何指令，比如处于 sleep、wait、park 状态，或者正在执行 native 方法。它们无法及时响应安全点轮询，也就无法进入 STW。
安全区域解决这个问题：当线程进入这些“已知安全”的长时间阻塞状态时，会标记自己已进入 Safe Region；GC 发起时，会跳过这些线程；当它们准备恢复执行时，再检查是否需要先到达安全点再继续。
- 典型场景包括：Object.wait()、Thread.sleep()、LockSupport.park()、JNI native 调用期间；
- 这避免了 GC 无限等待某条休眠线程“醒来”，提升了 STW 的可控性；
- 但要注意：如果大量线程长期停留在 Safe Region（如频繁 wait/notify 不平衡），仍可能导致 GC 延迟升高。
System.gc() 和 Safepoint 是 JVM 底层协同工作的两个环节：前者是上层请求入口，后者是底层执行前提。它们共同体现了 JVM 在自动内存管理中对“正确性”与“可控性”的权衡——宁可多等一会儿，也不能错收一个对象。
