jvm垃圾回收器对系统延迟的影响本质在于stw发生的时机、时长、可预测性与可控性：serial/parallel全程stw，cms仅初始与重新标记阶段stw但可能退化，g1通过region分区实现毫秒级可控停顿，zgc/shenandoah则将最大stw压至10ms内。
JVM 垃圾回收器对系统延迟的影响，本质不是“会不会停顿”，而是“停顿发生在哪、持续多久、是否可预测、是否可控”。它直接决定服务响应的毛刺率、P99/P999延迟稳定性，甚至影响熔断、降级等容错机制的触发逻辑。
Stop-The-World 是延迟的根源，但不同回收器控制方式差异巨大
所有主流GC在关键阶段都需暂停用户线程（STW），但暂停的范围、频率和时长天差地别：
- Serial / Parallel GC：新生代和老年代回收均全程STW。一次Full GC可能停顿数百毫秒甚至数秒，对HTTP接口或RPC调用而言，就是明显的请求超时或重试风暴。
- CMS：仅初始标记和重新标记阶段STW，其余并发进行。但一旦并发失败（Concurrent Mode Failure），会退化为Serial Old，触发长时间STW，延迟不可控，这也是它被JDK 9废弃的核心原因。
- G1：通过Region分区和增量式回收，将STW拆分为多个短暂停顿，并以-XX:MaxGCPauseMillis为目标进行预测性调度。实际停顿通常控制在几十毫秒内，但若堆过大或对象晋升过快，仍可能突破目标。
- ZGC / Shenandoah：几乎全部并发执行，最大STW时间稳定在10ms以内（ZGC标称
延迟不只是GC停顿，还有隐性开销
GC带来的延迟成本常被低估，除了显式的STW，还包括：
- 写屏障（Write Barrier）开销：G1、ZGC、Shenandoah依赖写屏障维护对象图一致性。每次对象字段赋值都会触发轻量级逻辑，带来CPU周期损耗，尤其在高频更新场景（如缓存刷新、事件总线）中会抬高平均延迟。
- 内存带宽竞争：并发GC线程与应用线程共享内存总线。在大堆+高吞吐场景下，GC线程大量读写内存页，可能造成应用线程缓存失效（cache miss）加剧，间接拉高响应时间。
- TLAB耗尽与同步分配：当线程本地分配缓冲区（TLAB）不足时，对象分配会回退到共享Eden区并加锁。若大量线程同时耗尽TLAB，将引发锁争用，表现为分配延迟突增，常被误判为GC问题。
延迟波动往往暴露配置与代码协同缺陷
稳定的低延迟需要GC策略与业务特征严格匹配：
- 若应用创建大量短期小对象（如日志拼接、JSON序列化中间体），但新生代过小或Survivor区太小，会导致对象频繁提前晋升至老年代，引发老年代GC频次上升，延迟毛刺增多。
- 若使用G1却未设置-XX:G1HeapRegionSize适配大对象（≥½ Region），大对象只能进入Humongous区，而Humongous区回收不参与常规GC周期，易堆积并最终触发整堆回收。
- 反射、动态代理、Lambda生成类等行为会持续向元空间（Metaspace）注入类，若-XX:MaxMetaspaceSize设得过小或未监控，元空间GC也会触发STW，且容易被忽略。
可观测性是延迟治理的前提
不能只看“有没有GC”，而要看“GC如何影响延迟”：
- 启用详细GC日志：-Xlog:gc*,gc+age=trace,safepoint（JDK 11+），重点关注safepoint进入等待时间（即应用线程卡在哪儿等GC）、各阶段耗时分布。
- 结合JFR（Java Flight Recorder）采集端到端请求链路，叠加GC事件标记，可精准定位某次P99延迟飙升是否由某次Young GC的STW或写屏障抖动引起。
- 监控JVM指标如jvm_gc_pause_seconds_count（Prometheus）、SafepointSyncTime、SafepointTotalTime，比单纯看GC次数更能反映真实延迟压力。
