jvm垃圾回收调优需在吞吐量、延迟和内存占用间求平衡，核心是监控停顿时间、吞吐量、gc频率与耗时分布、内存趋势等指标，结合结构化日志与持续观测，从异常指标反推根因，并通过单变量调整、周期验证实现闭环优化。
JVM 垃圾回收性能调优不是追求单点最优，而是围绕业务真实需求，在吞吐量、延迟和内存占用之间找到合理平衡。关键不在于参数堆得多，而在于指标看得清、问题判得准、动作调得稳。
核心性能指标必须监控到位
GC行为是否健康，不能靠感觉，要靠可观测数据支撑：
- 停顿时间（Pause Time）：每次GC导致应用线程暂停的时长，尤其关注Young GC和Full GC的P99/P999值。Web/API类服务通常要求单次停顿 ≤ 100ms，ZGC目标是 ≤ 10ms。
-
吞吐量（Throughput）：应用实际运行时间占总时间的比例，公式为
运行时间 / (运行时间 + GC时间)。批处理任务常要求 ≥ 99%。 - GC频率与耗时分布：Young GC应高频短时（如每秒数次、每次几毫秒）；Full GC应极少发生（理想是零次/天），若频繁出现（如每小时多次），大概率存在内存泄漏或晋升异常。
- 内存使用趋势：观察老年代长期占用率是否缓慢爬升（暗示内存泄漏）、Eden区每次GC后剩余比例是否稳定（反映对象存活率是否异常升高）。
指标采集需规范且持续
光看数字没用，采集方式决定诊断质量：
- 启用结构化GC日志：
-Xlog:gc*,gc+heap=debug,gc+age=trace:file=gc.log:time,tags,level（JDK 10+），避免旧版-XX:+PrintGCDetails的解析困难。 - 生产环境务必开启日志滚动与压缩，防止磁盘打满；建议保留至少7天历史日志。
- 配合
jstat -gc <pid> 1s</pid>实时观测，或集成Prometheus + JMX Exporter做长期趋势分析。 - 不依赖单次快照，关注连续5–15分钟内的指标波动模式（例如：某次Full GC后老年代回收率极低，可能预示碎片化严重）。
从指标反推常见问题类型
指标异常往往对应典型根因，可快速定位方向：
- Young GC频繁 + Eden回收率低 → 对象存活时间变长，可能有缓存未设淘汰策略、ThreadLocal未清理、或新生代过小。
- Full GC频繁 + 老年代回收前后占用几乎不变 → 内存泄漏（如静态集合不断add）、或大对象直接分配触发担保失败。
- 单次GC停顿远超预期（如G1设了-XX:MaxGCPauseMillis=200，却出现800ms停顿） → 可能并发标记阶段被中断、Mixed GC选Region过多、或元空间耗尽触发Full GC。
- GC时间占比高但停顿不长 → 多是Young GC次数爆炸（如每秒上百次），本质是分配速率过高，需检查对象创建热点或调整新生代大小。
调优动作必须闭环验证
改完参数不算结束，必须确认指标是否向好：
- 每次仅调整一个变量（如只改-Xmx，不动NewRatio），便于归因。
- 观察窗口不少于2个完整业务周期（如电商系统覆盖早高峰+晚高峰）。
- 对比基线：记录调优前30分钟平均值，再对比调优后同等负载下的变化。
- 接受“无变化”结果：某些场景（如I/O密集型应用）GC本身并非瓶颈，强行调优反而引入新风险。
指标是镜子，不是答案。看清它，才能知道该往哪走。
