Java垃圾回收调优关键在于“配得准、看得清、动得稳”，需结合业务场景（低延迟/高吞吐/大堆/内存受限）匹配GC算法与参数组合，协同设置核心参数，依据对象生命周期调整分代策略，并通过GC日志和三大硬指标验证效果。
Java 垃圾回收高级进阶，不是堆参数调大就行，关键在“配得准、看得清、动得稳”。配的不是参数本身，而是参数与业务特征、GC目标、硬件资源之间的匹配关系。
明确你的 GC 目标
不同场景，GC 的优先级完全不同：
- 低延迟敏感型（如实时交易、高频接口）：优先选 ZGC 或 Shenandoah，目标是单次停顿 ≤10ms，哪怕吞吐略降也接受；
- 高吞吐导向型（如批处理、离线计算）：用 Parallel GC + 合理 Young/Old 比例，允许较长 STW，但要压住 Full GC 频率；
-
大堆稳态服务（如风控引擎、消息中台，堆 >8GB）：G1 是默认起点，需重点调优 Region 大小、Mixed GC 触发阈值和最大 GC 时间目标（
-XX:MaxGCPauseMillis）； - 内存受限环境（如容器化微服务，限制 512MB~2GB）：禁用 G1/ZGC，回归 Serial 或轻量 Parallel，并严格控制元空间和直接内存上限。
核心参数组合不能孤立设置
单设 -Xmx 或 -XX:MaxGCPauseMillis 很容易失效。必须成组协同：
-
G1 场景：设
-XX:+UseG1GC后，必须同步定-XX:G1HeapRegionSize（建议 1–4MB，避免过大导致回收粒度粗）、-XX:InitiatingOccupancyPercent（默认 45%，若 Old 区增长快可调至 35–40）、-XX:G1MixedGCCountTarget（控制 Mixed GC 次数，防碎片堆积）； -
ZGC 场景：启用
-XX:+UseZGC后，-XX:SoftRefLRUPolicyMSPerMB要收紧（默认 1000，可设为 100），避免软引用拖慢回收；同时必须配-XX:+UnlockExperimentalVMOptions -XX:ZCollectionInterval=5（主动触发周期回收，防突发压力）； -
通用底线：永远加上
-XX:+PrintGCDetails -Xlog:gc*:file=gc.log:time,tags（JDK10+），不看日志的调优等于盲调。
对象行为决定分代策略
参数要跟着对象生命周期走，而不是拍脑袋定比例：
立即学习“Java免费学习笔记（深入）”；
- 如果监控发现
Young GC后大量对象幸存（Survivor 空间频繁溢出、Tenuring Threshold 低于 1），说明对象“活得太久”，应调大 Young 区（-XX:NewRatio或-Xmn），或启用-XX:+AlwaysTenure（强制升代，避免 Survivor 拷贝开销）； - 若 Old 区缓慢上涨、Full GC 偶发但耗时长，大概率是内存泄漏或大对象直入老年代——先用
-XX:+HeapDumpOnOutOfMemoryError抓堆快照，再用 MAT 查 Dominator Tree，别急着调-XX:MaxTenuringThreshold； - 短生命周期小对象密集（如 JSON 解析、HTTP 请求体）：开启 TLAB（默认已开），并调大
-XX:TLABSize和降低-XX:TLABWasteTargetPercent，减少线程间竞争分配锁。
验证调优是否真正生效
跑完一轮参数修改后，只看“没 OOM”不够，要盯三个硬指标：
- GC 吞吐率：（应用运行时间 / 总时间）≥98%（生产环境底线）；
- 平均停顿：连续 1 小时内，90 分位 GC pause ≤ 目标值（如 ZGC ≤8ms，G1 ≤200ms）；
- Old 区趋势：观察 24 小时 Old 区使用曲线，应呈锯齿状波动，而非持续缓升——缓升即隐性泄漏。
不复杂但容易忽略。
