垃圾收集器调优是基于应用特征、GC行为观测与吞吐量/延迟/内存占用三者权衡的系统性工作，盲目调堆或换算法常适得其反；Web API优先保延迟（G1/ZGC），ETL重吞吐（Parallel GC），资源受限场景需慎选Region大小与晋升策略。
垃圾收集器调优不是靠堆参数“堆”出来的，而是基于应用特征、GC行为观测与目标权衡的系统性工作。盲目增大堆、强行切换GC算法，往往适得其反。
明确吞吐量、延迟、内存 footprint 三者不可兼得
这是调优的底层逻辑。高吞吐（如批处理）可接受较长但不频繁的STW；低延迟（如实时交易）要求GC停顿严格控制在几毫秒内；小内存 footprint（如容器化部署）则需在有限堆空间内减少浮动垃圾和内存碎片。选型前先回答：你的应用最不能容忍什么？
- Web API 服务通常优先保延迟，适合 G1 或 ZGC
- 离线 ETL 任务更看重吞吐，Parallel GC 往往更稳
- 资源受限的微服务（如 512MB 堆）慎用 G1，默认 Region 大小可能引发过早晋升
关键参数要理解语义，而非死记数值
每个核心参数背后都有明确的设计意图，脱离场景谈推荐值意义不大：
- -Xms 与 -Xmx 必须相等：避免运行时堆动态扩容带来的额外开销和内存抖动，尤其在容器中（cgroup 内存限制下扩容可能失败）
- -XX:MaxGCPauseMillis=N（G1/ZGC）是软目标，不是硬承诺——它影响 GC 触发时机和并发线程数，但无法保证每次都不超时
- -XX:G1HeapRegionSize不能乱设：太小 → Region 数过多，元数据开销大；太大 → 小对象浪费严重，跨 Region 引用增多；默认值（根据堆大小自动推导）多数情况下最优
- -XX:+UseStringDeduplication（G1）对含大量重复字符串的场景（如日志解析、JSON 解析）有效，但会增加 GC 遍历时间，需实测收益
调优必须依赖真实 GC 日志 + 可视化分析
没有日志的调优等于蒙眼开车。开启基础日志是底线：
- JDK 8/9+ 推荐：-Xlog:gc*,gc+heap=debug,gc+ergo*=debug:file=gc.log:time,tags,uptime
- 至少包含：GC 类型（Young/Old/Mixed）、耗时（real/user/sys）、各代变化、是否失败（如 Evacuation Failure）、元空间使用情况
- 用 GCViewer、GCEasy 或 Prometheus + Grafana（配合 jvm_gc_collection_seconds_count）做趋势分析，重点关注：YGC 频率是否陡增、Old GC 是否从偶尔变为高频、MetaSpace 是否持续增长
常见误判与应对信号
很多“问题”其实是正常现象，而真正的问题常被忽略：
- 频繁 YGC ≠ 内存泄漏：可能是分配速率高（如短生命周期对象多），先看 Eden 区是否每次都能清空、Survivor 是否长期闲置
- Old GC 后老年代占用不降：大概率存在强引用对象堆积（缓存未清理、监听器未注销、ThreadLocal 泄漏），不是调 GC 参数能解决的
- G1 Mixed GC 持续执行却不清老年代：说明待回收 Region 中存活对象比例过高（> G1MixedGCLiveThresholdPercent，默认85%），需检查对象晋升策略或减少长生命周期对象
- ZGC 出现长时间“Pause Mark Start”：往往因 Java 线程被 OS 调度挂起（如 CPU 抢占、容器配额不足），而非 GC 自身慢
