核心问题是gc策略与对象生命周期不匹配，需同步优化回收器选型（如g1/zgc）、堆结构（固定大小、合理分代比）及代码层对象分配（避免隐式晋升与大对象干扰），并结合gc日志与工具验证。
JVM 垃圾回收停顿时间过长，核心问题往往不在堆大小本身，而在于 GC 策略与应用对象生命周期不匹配、参数配置失当或代码层隐性内存压力。优化要从回收器选型、堆结构配置、对象分配行为三方面同步切入，不能只调一个参数了事。
选对回收器并设准目标停顿
停顿超预期，第一步先看是否用错了回收器：
- Web API、实时风控等低延迟服务，禁用 ParallelGC（默认吞吐优先，单次 Full GC 可达数秒），改用 -XX:+UseG1GC；JDK 11+ 且堆 ≥8GB、要求亚十毫秒停顿的场景，可评估 ZGC 或 Shenandoah，但需确认无 JNI 兼容风险
- G1 必须配 -XX:MaxGCPauseMillis=30～200（单位毫秒），这是 JVM 动态调整年轻代大小和混合回收节奏的依据；设太低（如 10）反而触发更频繁回收，CPU 升高、停顿毛刺增多
- CMS 已废弃（JDK 14 起移除），若仍在用，务必加 -XX:+UseCMSInitiatingOccupancyOnly，否则 JVM 会动态覆盖触发阈值，导致突发 Concurrent Mode Failure 退化为 Full GC
固定堆结构，避免隐式晋升
老年代频繁回收引发长停顿，多数源于对象过早进入老年代：
- 堆大小必须固定：-Xms4g -Xmx4g（数值按实际负载定），避免运行时扩容缩容带来的额外 GC 抖动
- 新生代不能太小：G1 下建议 -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=60，缓解 Minor GC 频率；Parallel 下可用 -XX:NewRatio=2（新生代占堆 1/3）
- 大对象直入老年代是常见诱因：若业务存在 >512KB 对象（如日志拼接字符串、未分片缓存集合），显式设 -XX:G1HeapRegionSize=1M，减少跨 Region 引用和 Remembered Set 维护开销
- 检查 Survivor 区是否“装不下”：若 GC 日志中显示大量对象在 Survivor 未满就晋升，说明 -XX:SurvivorRatio=6 不够用，或 -XX:MaxTenuringThreshold 设得过高（默认 15），可调低至 4～6
从代码层减少 GC 压力
很多 STW 延长不是 GC 慢，而是应用在“主动喂垃圾”：
- 循环内避免 new StringBuilder().append(...).toString()，生成大量短命大字符串，极易直接进老年代
- ThreadLocal 不要存放大 Map、DB 连接池等长生命周期对象，线程复用下易滞留内存，GC 时需扫描整个 ThreadLocalMap
- 日志框架（如 Logback）慎用 %X{traceId} 绑定非常驻 MDC，每次请求 new 一个 Map 会显著抬高 Eden 分配速率
- 用基本类型替代包装类（int 优于 Integer），减少自动装箱带来的短期对象；构造开销大的对象（如 HttpClient、Socket）考虑对象池，但非所有场景都适用
靠真实数据验证，不靠猜测
平均停顿没意义，关键看毛刺和阶段耗时分布：
- 开启详细 GC 日志：-Xlog:gc*,gc+phases:file=gc.log:time,uptime,tags（JDK 10+），重点关注 Evacuation 阶段中 Root Region Scan 和 Remembered Set Processing 占比
- 用 jstat -gc -h10
1000 持续采样，观察 G1YGC/G1FGC 频次、各区域使用率波动；若 FGC 频繁但老年代回收量极小，可能是元空间泄漏或类加载器未释放 - 导入 gc.log 到 GCViewer 或 GCEasy，看是否有 Concurrent Mode Failure、Humongous Allocation 高频出现——这些才是真正的瓶颈信号
