调优应先看信号：Full GC频繁、响应延迟突增、老年代使用率＞75%、GC overhead OOM、Survivor溢出；再选收集器（如G1适合大堆），最后调-XX:MaxGCPauseMillis、-XX:G1HeapRegionSize等参数，用GC日志和监控验证效果。
JVM 垃圾回收性能调优实战教程怎么写
直接写可落地的调优过程，不堆概念、不讲原理推导，重点说清楚“什么时候该调”“改哪几个参数”“怎么验证有效”。读者打开就能照着做，遇到问题能快速定位。
明确调优目标和触发信号
调优不是为了追求某个指标好看，而是解决真实痛点。常见需介入的信号包括：
- Full GC 频繁（例如每小时超过 3 次），且每次耗时 >1 秒
- 应用响应延迟突增，监控显示 GC 时间占比持续 >10%
- 老年代使用率长期 >75%，且缓慢上涨不下降
- 出现 java.lang.OutOfMemoryError: GC overhead limit exceeded
- 年轻代对象晋升过快，Survivor 区反复溢出（通过 -XX:+PrintGCDetails 可观察）
选对收集器，再调参数
不同场景默认收集器差异大，盲目调参不如先换对“工具”：
- 单机小应用（：用 Serial 或 Parallel（-XX:+UseParallelGC），调好 -Xmx/-Xms 和 -XX:MaxGCPauseMillis 即可
- Web 服务（4–16C、内存 8–32G、要求停顿 ：优先选 G1（-XX:+UseG1GC），重点调 -XX:MaxGCPauseMillis（建议 200–400）、-XX:G1HeapRegionSize（默认 2MB，大对象多时可设为 4M）、-XX:G1NewSizePercent（10–20）
- 超大堆（>32G）、延迟敏感（如金融交易）：ZGC（JDK 11+）或 Shenandoah（JDK 12+），开启即见效，参数极少，-XX:+UseZGC -Xmx32g 是典型起步配置
别在 CMS 上折腾——它已在 JDK 14 中移除，G1 已足够覆盖绝大多数场景。
三步实操调优流程
拿一个典型的 Spring Boot 应用（8C/16G，G1 收集器）为例：
-
第一步：加基础监控参数启动
-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -
第二步：压测中采集数据
用 JMeter 跑 10 分钟稳定流量，观察 gc.log 中：平均 GC 间隔、Young GC 耗时分布、Mixed GC 触发频率、是否发生 Full GC、老年代最大占用峰值 -
第三步：针对性调整
若 Mixed GC 太频繁 → 增大 -XX:G1HeapWastePercent（默认 5，可试 10）
若 Survivor 区总溢出 → 调大 -XX:G1ReservePercent（默认 10，可试 15）
若 MetaSpace 报 OOM → 加 -XX:MaxMetaspaceSize=512m（避免无限增长）
验证是否真的变好
不能只看 GC 次数减少，要交叉比对：
- 应用 P99 响应时间是否下降（尤其 GC 后那几秒）
- 系统 CPU 使用率是否更平稳（避免 GC 线程抢资源）
- 吞吐量（QPS）是否持平或提升（说明有效时间变多）
- 用 jstat -gc <pid> 1s 实时看 Eden/Survivor/Old 使用率变化节奏是否更健康
一次调参后至少跑 2 轮相同压力测试，取均值对比。单次波动不能说明问题。
