优化JVM GC需匹配对象生命周期与响应要求，优先选G1GC（-XX:+UseG1GC）并设目标停顿（-XX:MaxGCPauseMillis=50），配固定堆（-Xms4g -Xmx4g）、合理分代比（NewRatio=2，SurvivorRatio=6），避免隐式晋升与大对象干扰，结合日志（-Xlog:gc*）与工具（jstat、GCViewer）验证效果。
优化 JVM 垃圾回收频率与停顿时间，关键在于让 GC 行为匹配应用的真实对象生命周期和响应要求。不是堆越大越好，也不是回收器越新越优，而是参数、策略与代码习惯三者协同。
选对回收器并设准目标停顿
低延迟服务（如 API 网关、实时风控）优先用 G1GC，并显式启用：
-XX:+UseG1GC
再通过 -XX:MaxGCPauseMillis=50 设定目标（注意：是目标，非硬性保证）。G1 会据此动态调整年轻代大小、混合回收节奏和 Region 扫描范围。设得太低（如 10ms）反而触发更频繁的回收，增加 CPU 开销。ZGC 或 Shenandoah 适合 JDK 11+ 且堆 >8GB 的场景，但需确认业务兼容性——比如是否依赖 JNI 或特定字节码操作。
合理配置堆与分代比例
避免堆大小浮动带来额外开销：
-Xms4g -Xmx4g（初始与最大一致）
新生代过小会导致 Minor GC 频繁；过大则延长单次停顿。常用经验比例如下：
• -XX:NewRatio=2：老年代 : 新生代 = 2:1
• -XX:SurvivorRatio=6：Eden : 单个 Survivor = 6:1（即两个 Survivor 共占新生代 1/4）
若日志显示大量对象在 Survivor 区未满就晋升，说明 Survivor 太小或 -XX:MaxTenuringThreshold 设得过高，可适当调高 Survivor 比例或降低晋升阈值。
减少隐式晋升与大对象干扰
很多 STW 延长并非来自堆大小，而是对象分配失当：
• 避免在循环中反复 new StringBuilder().append(...).toString()，生成大量短命大字符串，易直接进入老年代
• 不要用 ThreadLocal 存放缓存 Map 或 DB 连接池，线程复用下极易滞留内存
• 日志框架中慎用 %X{traceId} 绑定非常驻 MDC，每次请求 new 一个 Map 会显著抬高 Eden 分配速率
• 若应用存在大量 >512KB 的对象，可尝试 -XX:G1HeapRegionSize=1M（默认自动推导），减少跨 Region 引用，降低 Remembered Set 维护成本
靠日志和工具验证真实效果
别只看平均停顿，要抓毛刺：
• 启用详细 GC 日志：
-Xlog:gc*,gc+phases:file=gc.log:time,uptime,tags（JDK 10+）
• 用 jstat -gc -h10 <pid> 1000 持续采样，观察 G1YGC/G1FGC 频次与耗时波动
• 导入 gc.log 到 GCViewer，重点关注 Evacuation 阶段中 Root Region Scan 和 Remembered Set Processing 耗时占比
若发现 Concurrent Mode Failure 频发，说明并发标记跟不上分配速度，需调低 -XX:InitiatingHeapOccupancyPercent（如从默认 45 改为 35）或增大堆预留空间
