Java垃圾回收暂停时间过长的核心是回收策略与应用对象生命周期不匹配；应优先启用G1GC（-XX:+UseG1GC）并设合理目标停顿（-XX:MaxGCPauseMillis=150–250），避免盲目调参或过早切换ZGC/Shenandoah。
Java 垃圾回收暂停时间过长，核心问题不是“GC 太慢”，而是回收策略与应用行为不匹配。真正有效的调优，是让 GC 更懂你的对象生命周期，而不是盲目堆参数。
选对回收器并设准目标停顿
G1 是当前 JDK 8–22 主流低延迟场景的首选，它专为可控 STW 设计，而非追求吞吐量最大化。
- 必须显式启用：-XX:+UseG1GC
- 设定合理目标值：-XX:MaxGCPauseMillis=150–250（单位毫秒）。设太低（如 10 或 50）会迫使 G1 频繁触发小规模回收，反而抬高 CPU 和总停顿；设太高则失去控制意义
- 避免无脑切换 ZGC/Shenandoah：它们在 JDK 11+ 才趋于稳定，且对超大堆（>16GB）、极严延迟（
防止老年代失控导致退化 Full GC
G1 一旦退化为单线程 Serial GC，STW 就会飙升至秒级，直接引发接口超时。关键在于让 Mixed GC 持续有效工作。
- 提前启动并发标记：-XX:InitiatingHeapOccupancyPercent=35–45（默认 45），尤其当老年代增长快时，下调可抢出回收窗口
- 聚焦有价值回收区域：-XX:G1MixedGCLiveThresholdPercent=85（默认 65），避免浪费资源清理“太干净”的 Region
- 预留缓冲空间防崩溃：-XX:G1ReservePercent=15–20，防止 Mixed GC 过程中因无空闲 Region 而强退 Full GC
- 检查日志中是否频繁出现 Full GC (Ergonomics) 或 Concurrent Mode Failure，这是退化的明确信号
优化对象分配与晋升行为
很多 STW 延长，源头不在 GC 算法，而在代码悄悄把对象“送进火坑”——比如本该死在年轻代的对象，被提前塞进老年代。
- 降低晋升年龄阈值：-XX:MaxTenuringThreshold=6（默认 15），加快短期对象在 Survivor 区自然消亡
- 控制大对象直入老年代：-XX:PretenureSizeThreshold=1048576（1MB），避免中等大小缓存、JSON 解析结果等误判为“巨大”而跳过年轻代
- 避免隐式晋升：检查 -XX:+PrintGCDetails 日志中每次 Young GC 后晋升老年代的字节数，若持续高于老年代剩余空间，说明 Survivor 区太小或对象存活率异常高
- 慎用 ThreadLocal 存放大对象、Logback 的 MDC 每次 new Map、循环中反复 toString() 大 StringBuilder——这些都会显著推高年轻代分配速率和晋升压力
验证调优是否真实生效
不看日志的调优等于盲调。重点不是平均值，而是毛刺和阶段耗时分布。
- 开启细粒度日志：-Xlog:gc*,gc+phases:file=gc.log:time,uptime,tags（JDK 10+）
- 关注 Evacuation 阶段中 Root Region Scan 和 Remembered Set Processing 耗时占比——若两者占 STW 大头，说明跨代引用过多，需优化对象图结构或调大 -XX:G1RSetUpdatingPauseTimePercent
- 用 jstat -gc -h10
1000 持续采样，观察 G1YGC/G1MixedGC 频次与单次耗时波动，识别周期性尖峰 - 禁用 -XX:+UseStringDeduplication（除非确认有海量重复字符串），它会在 STW 期间加锁扫描，延长停顿
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
