JVM垃圾回收是响应式行为，由内存压力触发而非定时执行。年轻代填满触发Minor GC，老年代达阈值或分配失败触发Major/Full GC；G1、ZGC等可利用空闲周期辅助回收；参数可调回收节奏，System.gc()不可靠。
JVM 垃圾回收不是定时闹钟，也不会按固定秒数执行，而是由内存状态、运行环境和人工配置共同决定的响应式行为。它不依赖时间戳，但可通过参数间接影响触发节奏。
堆内存压力是核心触发信号
JVM 主动监控各内存区域的使用水位，一旦达到预设阈值，立刻启动对应级别的回收：
- 年轻代（Eden 区）填满时，触发 Minor GC —— 这是最频繁的一类回收，主要清理“朝生夕死”的对象；
- 老年代占用率升至阈值（默认约 70%–80%，可通过 -XX:MetaspaceSize 或 -XX:OldPLabSize 类参数微调），可能触发 Major GC 或 Full GC；
- 当新对象分配失败、且 Minor GC 后仍无法腾出足够空间时，JVM 会强制发起 Full GC 尝试抢救；若仍失败，则抛出 OutOfMemoryError。
系统资源空闲时可辅助触发
部分垃圾收集器（如 G1、ZGC）具备自适应调度能力，在检测到 CPU 负载较低、应用线程暂停间隙较多时，会主动利用空闲周期提前执行部分回收工作（如并发标记、部分清理），降低后续 STW（Stop-The-World）压力。
这种行为不可控、不保证发生，属于 JVM 的优化策略，而非用户可配置的“定时任务”。
显式配置可改变回收节奏与边界
虽然不能直接设定“每5分钟GC一次”，但通过 JVM 参数能显著影响触发频率和时机：
- -Xms 和 -Xmx 设定堆初始与最大容量 —— 堆越小，越容易填满，Minor GC 更频繁；堆过大则可能导致单次 GC 停顿变长；
- -XX:NewRatio 或 -XX:SurvivorRatio 调整新生代占比 —— 新生代小，Eden 更快填满，Minor GC 更密；
- -XX:MaxTenuringThreshold 控制对象晋升老年代的年龄 —— 提前晋升可能加剧老年代压力，间接诱发更早的 Major GC；
- -XX:+UseG1GC 等收集器选择，决定了是否启用预测式回收（如 G1 的目标停顿时间 -XX:MaxGCPauseMillis），让 JVM 动态调整每次回收的工作量。
代码中调用 System.gc() 并非可靠手段
该方法仅向 JVM 发出“建议回收”的信号，是否执行、何时执行完全由 JVM 决定（尤其在开启 -XX:+DisableExplicitGC 时会被忽略）。生产环境通常禁用此调用，避免干扰 GC 自主调度逻辑。
真正可控的，是内存布局与回收策略的设定；真正不可控的，是具体某次 GC 发生的毫秒级时刻 —— 它永远服务于内存健康，而非人为钟表。
