java生产环境gc调优需基于可观测数据、明确业务sla目标（低延迟/高吞吐/内存密集型）及分阶段验证；优先固定堆大小，按对象生命周期调年轻代，g1用maxgcpausemillis目标驱动，zgc/shenandoah关注xmx和软引用策略，并持续监控告警回滚。
Java 生产环境的垃圾回收调优不是靠猜，而是基于可观测数据 + 明确目标 + 分阶段验证。核心是让 GC 频率合理、停顿可控、吞吐不跌，而不是追求“零 Full GC”或“最短 STW”这种脱离业务的指标。
明确业务场景和 SLA 约束
调优前必须回答三个问题：应用是低延迟敏感（如交易下单）、高吞吐优先（如批处理）、还是内存密集型（如缓存服务）？GC 停顿能否接受 100ms？每分钟最多容忍几次 >50ms 的暂停？日均 Full GC 次数上限是多少？这些决定了你选 G1、ZGC 还是 Shenandoah，也决定了你是否要压低堆内存或调整年轻代比例。
先看真实 GC 日志，再动手改参数
开启基础 GC 日志（-Xlog:gc*,gc+heap=debug,gc+ergo*=info:file=/path/gc.log:time,tags,uptime,level），运行至少 2~3 个典型业务周期（比如一个完整交易高峰）。重点观察：
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 年轻代回收频率和平均耗时（是否频繁 Minor GC？是否每次都晋升大量对象？）
- 老年代内存增长趋势（是缓慢爬升后突爆 Full GC，还是阶梯式上涨？）
- GC 后老年代占用是否持续升高（暗示内存泄漏或缓存未清理）
- 是否存在 Humongous 分配失败（G1 下大对象直接进老年代引发问题）
分阶段调整，每次只动一两个关键参数
不要一上来就堆参数。推荐顺序：
- 先固定堆大小（-Xms = -Xmx），避免动态扩容带来的额外 GC 和内存抖动
- 根据对象生命周期调年轻代（-XX:NewRatio 或 -Xmn）：短生命周期多则加大年轻代；若 Survivor 区总溢出，调 -XX:SurvivorRatio 或启用 -XX:+AlwaysTenure
- G1 场景下，优先用 -XX:MaxGCPauseMillis 设目标（如 200ms），让 JVM 自适应；再配合 -XX:G1HeapRegionSize 避免大对象误判
- ZGC/Shenandoah 重点关注 -Xmx 和 -XX:SoftRefLRUPolicyMSPerMB（软引用回收策略），它们对停顿影响更直接
上线后持续监控与回滚机制
调优不是一次性的。把 GC 吞吐量（GC time / total time）、各代使用率、STW 时间 P99/P999 接入 Prometheus + Grafana。设置告警：连续 5 分钟 Full GC > 2 次，或单次 STW > 500ms 自动触发告警并切回上一版 JVM 参数。生产环境宁可保守，也不要为省几百 MB 内存而赌一次长停顿。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
