System.gc() 不设定执行周期，它不参与 JVM 的自动 GC 调度节奏，也不改变垃圾收集器的运行频率或触发条件。
它只是个“建议”，不是指令
调用 System.gc() 仅向 JVM 发出一个友好提示：「当前可能适合做一次 Full GC」。JVM 可以选择立即响应、延迟执行，甚至完全忽略。是否执行、何时执行、执行哪类 GC（如 Serial、G1 或 ZGC 的具体行为），完全取决于：
- 所用垃圾收集器的实现策略（例如 G1 默认会将 System.gc() 视为 Full GC 请求，而 ZGC 和 Shenandoah 在默认配置下会忽略它）；
- JVM 启动参数（如 -XX:+DisableExplicitGC 会直接屏蔽所有 System.gc() 调用）；
- 当前堆内存压力（内存充足时更可能被跳过）。
与不同收集器的典型交互表现
不同 GC 算法对 System.gc() 的响应逻辑差异明显：
- Serial / Parallel GC：通常会触发一次 Full GC（老年代 + 新生代），但仍不保证即时性；
- G1 GC：默认将其转为一次 Full GC（尽管 G1 设计本意是避免 Full GC），可通过 -XX:+ExplicitGCInvokesConcurrent 改为触发并发 GC（类似 Mixed GC 行为）；
- ZGC / Shenandoah：在默认模式下不响应 System.gc()，因其设计为全程并发、无停顿，显式 GC 请求无实际意义；若需强制，需配合特定参数（如 ZGC 的 -XX:+ZUncommitDelay=0 配合其他手段）。
它不影响分代回收的自然节奏
JVM 的常规 GC（Minor GC、Mixed GC、元空间回收等）完全由内存分配速率、空间阈值、对象晋升行为等驱动，和 System.gc() 无关。即使频繁调用 System.gc()，也不会让 Minor GC 更快发生，也不会改变 Survivor 区年龄阈值或大对象直接进入老年代的规则。它只可能额外插入一次全局停顿型回收（如果被采纳）。
真实场景中的风险提示
在生产环境滥用 System.gc() 容易引发问题：
- 造成不可预期的 STW（Stop-The-World）暂停，尤其在 Parallel 或 Serial 下 Full GC 停顿可能达秒级；
- 干扰 GC 日志分析——日志中突然出现的 Full GC 可能掩盖真实内存泄漏信号；
- 在容器化环境中（如 Kubernetes），可能触发 OOMKilled，因 Full GC 期间内存峰值升高且无法及时释放。
