降低JVM垃圾回收暂停时间的关键是匹配GC策略与应用负载，而非盲目调参；需选对回收器（如G1适用于4GB–64GB堆、中等延迟场景）、设合理目标、避开常见陷阱。
降低 JVM 垃圾回收暂停时间，核心不是“压参数”，而是让 GC 策略与应用实际负载匹配。关键在于选对回收器、设合理目标、避开常见陷阱。
选对回收器是前提
不同回收器设计目标不同，不能一概而论：
- G1 是 JDK 9+ 默认，适合堆大小在 4GB–64GB、延迟要求中等（
- ZGC / Shenandoah 适合超低延迟需求（目标
- Parallel GC 吞吐优先，单次 STW 可能达数百毫秒，不适用于响应敏感服务
- CMS 已废弃，JDK 14 起完全移除，不应再使用
用好 -XX:MaxGCPauseMillis 这个软目标
它不是硬限制，而是告诉 G1 “尽量控制在 X 毫秒内”，G1 会据此动态调优：
- 设为 200：多数 Web/API 服务适用，GC 频率适中，吞吐影响轻微
- 设为 100 或更低：需配合足够堆空间和 CPU 资源，否则易触发更频繁 Young GC，反而抬高整体 CPU 占用和吞吐损耗
- 设为 500：延迟容忍度高时可用，GC 更“懒”，但单次暂停可能变长，且老年代压力积累更快
- 必须搭配 -XX:+UseG1GC 才生效，对 Parallel 或 Serial GC 无效
配合关键参数协同调优
单靠 MaxGCPauseMillis 不够，还需调整配套策略：
- -XX:InitiatingHeapOccupancyPercent=45：避免并发标记启动太晚导致 Concurrent Mode Failure（退化为 Full GC），建议设为 40–50
- -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=60：给年轻代留出弹性空间，防止 Survivor 溢出导致对象过早晋升
- -XX:G1HeapRegionSize：若应用大量分配 >512KB 对象，可设为 1M 或 2M，减少跨 Region 引用和 Remembered Set 开销
- -Xms 和 -Xmx 设为相等：避免运行时堆扩容带来的额外开销，也利于 G1 预测更准
别忽视代码和日志层面的根因
参数调优见效的前提，是应用本身没“拖后腿”：
- 检查 GC 日志中是否频繁出现 G1 Evacuation Pause（年轻代回收）或 Concurrent Mode Failure（并发失败），后者说明并发标记跟不上分配速率
- 避免隐式晋升：如 Survivor 区太小、-XX:MaxTenuringThreshold 设得过高，导致中龄对象提前进老年代
- 减少大对象直接分配：比如循环中反复 new StringBuilder().toString() 生成大字符串，容易触发 Humongous Allocation，加剧碎片和 STW
- 慎用 ThreadLocal 存缓存、Logback 的 MDC 绑定非常驻上下文，都会显著抬高年轻代分配速率
