关键在于让gc节奏匹配业务节奏，明确吞吐量、延迟或内存占用的优先级：web/api与实时交易重低延迟（选g1/zgc），批处理重吞吐（选parallel gc），容器化场景重内存控制。
提升 JVM 内存回收性能，关键不是堆调得越大越好，也不是 GC 日志越少越优，而是让回收节奏匹配业务节奏——比如电商下单高峰时不能停顿，而后台报表任务可以接受稍长但更省资源的回收。
明确你的核心目标：吞吐量、延迟还是内存占用？
三者互相制约，必须先选准优先级：
- Web/API 服务、实时交易系统：重点压低 STW 时间，盯住 P95/P99 GC 停顿，G1 或 ZGC 是主流选择
- 批处理、ETL、定时导出任务：追求总运行时间最短，可倾向 Parallel GC，用 -XX:GCTimeRatio=19（即 GC 时间占比 ≤5%）控制吞吐量
- 容器化部署、边缘节点或内存敏感场景：限制堆上限（如 -Xmx512m），避免被 OOM kill，同时启用 -XX:+UseContainerSupport 让 JVM 正确感知 cgroup 限制
选对回收器，比调参更重要
JDK 8–17 推荐 G1；JDK 21+ 强烈考虑 ZGC（默认开启分代 ZGC），尤其适合堆 >4GB 的服务：
- G1 适用场景：堆 4–64GB，要求亚秒级停顿，且能接受少量浮动垃圾
- ZGC 适用场景：堆 ≥8GB，P99 停顿需稳定
- 慎用 CMS：JDK 9 起已废弃，JDK 14 彻底移除；Parallel Old 在大堆下 Full GC 易卡顿，不建议用于在线服务
堆与分代配置要“贴合对象生命周期”
不是套公式，而是看对象活多久：
- 如果监控发现大量对象在 Minor GC 后立刻进入老年代（promotion rate 高），说明 Survivor 区太小或晋升阈值过低，可调 -XX:SurvivorRatio=6 并确认 -XX:MaxTenuringThreshold 是否合理（默认 15，多数服务设为 6–8 更稳）
- 若老年代缓慢增长、长期不触发 GC，可能是缓存类对象堆积（如静态 Map、未清理的 ThreadLocal），优先查代码，而非调大老年代
- 新生代不宜过大：Eden 太大会拉长 Minor GC 时间；也不宜过小：频繁 Minor GC 会增加晋升压力。常用起点是堆的 1/3～1/2，再根据 GC 日志中 Eden 使用率动态调整
靠日志和工具验证，别靠猜
所有调优动作必须闭环验证：
- 加基础日志：-Xlog:gc*,gc+heap=debug,gc+age=trace:file=gc.log:tags,uptime,time（JDK 11+ 统一日志格式，替代旧版 -XX:+PrintGCDetails）
- 用 jstat -gc
1000 看 GC 频率与耗时趋势；用 jcmdVM.native_memory summary 排查堆外内存泄漏 - 关键指标盯住三项：Minor GC 间隔 ≥10s、Mixed GC 平均停顿 ≤200ms（G1）、ZGC Pause avg ≤10ms；超过即需干预
