做Java后端的人迟早会被GC问题找上门。我见过太多团队一遇到线上卡顿就搜“JVM调优参数”然后照着网上那份流传多年的命令抄一遍把-XX:MaxGCPauseMillis调到50、把-Xmx调大结果重启之后停顿反而更频繁。并不是参数错了而是很多人根本不清楚G1内部是怎么运作的更不知道ZGC应该在什么条件下才值得切换。这篇文章我会把G1的核心参数逐个拆开讲透同时说清楚ZGC的适用边界最后用一次完整的调优案例复盘从告警到参数落地的全过程。1. GC调优的边界先想清楚要不要调和调什么GC调优最忌讳一上来就动JVM参数。你需要先判断当前系统的GC压力到底来自哪里再决定是调参数、换收集器还是干脆改代码。很多情况下参数调整只是治标代码层面的问题才是根源。1.1 GC现象的根因分类分配速率、对象存活时间与停顿来源任何GC问题都可以归结为三个基础变量内存分配速率Allocation Rate、对象存活时间Object Lifetime和堆容量配置。这三个变量决定了GC触发的频率和单次GC的工作量。如果应用每秒分配100MB对象但绝大多数对象在年轻代就死亡那么Minor GC会被频繁触发但每次停顿很短。如果大量对象存活超过几个GC周期它们就会晋升到老年代最终触发Mixed GC甚至Full GC。真正的调优思路是识别你的应用属于哪种模式是高分配低存活还是低分配高存活。注意GC调优的目标从来不是消除GC而是让GC的停顿可控、频率合理。JVM无法避免GC但可以让你掌握GC的节奏。你可以在启动脚本中加入GC日志参数观察一段时间内的规律。我个人习惯用下面的组合收集基线数据比任何监控工具都直接-Xlog:gc*info:file/opt/logs/gc-%t.log:tags,uptime,level:filecount5,filesize64m这套参数会在每次重启时生成独立的GC日志文件保留5个、每个64MB轮转信息完整且不会撑爆磁盘。看到日志后重点看三件事Young GC的频率、各次GC后堆占用是否持续抬升、Mixed GC或Full GC的出现间隔。1.2 调优前的指标采集GC日志、JFR与实时监控的配合GC日志只是基础想定位具体是哪段代码在制造压力还需要结合JFRJDK Flight Recorder和实时监控数据。JFR是JDK自带的低开销采样工具开启后对应用影响极小通常低于1%。启动参数可以加-XX:StartFlightRecordingfilename/opt/logs/app.jfr,settingsprofile,duration15m等JFR跑15分钟左右用JMC打开文件直接看垃圾收集和对象分配两个视图。这里能直观看到分配速率最高的线程和调用栈定位到具体的类和方法。实时监控侧我建议至少关注四个指标老年代使用率、GC暂停时间P99、堆内存使用率趋势和GC线程CPU占用。很多团队只盯着堆使用率曲线看到涨到80%就紧张但真正应该关心的是老年代使用率是否在每次GC后能回落到合理水位。如果老年代每次GC后只能下降10%说明对象的晋升速率接近回收速率这是一个危险信号。2. G1核心参数逐个拆解从原理到操作的完整解读G1从JDK 9开始成为默认收集器它把堆划分为多个Region通过维护一个全局的回收优先级列表来决定每次回收哪些Region。G1的调优本质上是调节它对停顿目标和回收效率之间的权衡。理解了这一点参数就不会记混。2.1 MaxGCPauseMillis期望值不等于保证值-XX:MaxGCPauseMillis默认200ms是G1使用频率最高的参数也是误解最深的参数。它叫暂停时间目标不是暂停时间上限。G1会通过调整年轻代大小、回收Region数量等手段去尝试满足这个目标但代价可能是降低吞吐量、增加回收轮次。我的经验是不要把该值设到50ms以下。当目标过于激进时G1每次只回收很少的Region导致回收跟不上分配速率老年代持续堆积最终还是会在一次Mixed GC中集中爆发。常见的合理区间是100~300ms具体值取决于业务对延迟的容忍度。例如在线交易系统追求稳定一般设在100ms批处理任务对单次停顿不敏感设到500ms反而吞吐更高。一个容易被忽略的问题是MaxGCPauseMillis影响的不只是停顿时间它还间接决定了年轻代Region的数量。目标越短G1压得年轻代越小Young GC越频繁分配速率高的应用反而会因为年轻代太小而提前晋升对象。这类场景会出现一个典型现象GC频率上升但堆内存趋势没有改善。2.2 Region与年轻代比例HeapRegionSize、G1NewSizePercent与G1MaxNewSizePercentRegion大小是G1的物理基础。理论上G1希望堆能拆成约2048个Region所以不显式设置-XX:G1HeapRegionSize时JVM会根据堆大小自动推算。例如堆为4GBRegion就是2MB堆为32GBRegion就是16MB。多数情况下不需要手动指定Region大小但有一个例外当堆内存特别大比如64GB以上且对象大小分布极不均匀时默认Region可能过大或过小。Region过大浪费空间过小导致大对象跨Region增加回收复杂度。手动设置的原则是让Region不小于应用中占比最高的大对象体积通常用jmap -histo:live看一下对象分本就能判断。年轻代占比由-XX:G1NewSizePercent默认5%和-XX:G1MaxNewSizePercent默认60%控制。注意这里的百分比是相对整个堆的。G1会根据停顿目标动态调节年轻代大小但你仍然可以设一个下限防止年轻代被压得太狠。对于大多数Web应用默认值就够用真正值得关注的是Young GC的平均间隔和单次耗时。如果Young GC每秒触发好几次、每次耗时30~40ms说明年轻代太小或分配速率太高。这时候盲调G1NewSizePercent作用有限更合理的做法是先检查是否有大数组、大集合被反复创建把分配速率降下来。2.3 IHOP与混合回收Mixed GC的节奏控制IHOP全称是Initiating Heap Occupancy Percent它决定G1何时启动并发标记。默认值是45%意思是整个堆使用率达到45%时G1开始并发标记为后面的Mixed GC做准备。这个值太小会频繁触发标记浪费CPU太大则可能来不及标记导致最终Full GC。从JDK 8u40开始G1默认启用-XX:G1UseAdaptiveIHOP会根据历史GC数据自动调整IHOP。理论上很美好但实际中自适应IHOP依赖稳定的并发标记周期。如果应用内存使用率波动剧烈自适应值可能反复跳动造成Mixed GC节奏不稳定。定位到这类问题时我会显式关闭自适应手动设置一个偏保守的值。Mixed GC阶段还有两个参数容易被混淆-XX:G1MixedGCLiveThresholdPercent和-XX:G1HeapWastePercent。前者是Region内存活对象占比的阈值存活占比超过该值的Region在混合回收时会被跳过因为回不来多少空间后者是整个堆的可回收空间占比阈值低于该值时G1认为回收价值不大不再发起Mixed GC。经验值上如果堆中碎片化严重、大量Region存活率在70%以上可以试下调低G1MixedGCLiveThresholdPercent到85%让更多Region参与回收。但这类参数是场景相关的不要照搬。2.4 预留与线程参数ReservePercent、ParallelGCThreads与ConcGCThreads-XX:G1ReservePercent默认10%的含义是G1在堆中预留一部分空间用于晋升失败等突发情况。晋升失败指的是年轻代对象在GC过程中需要晋升到老年代但老年代没有足够连续空间触发担保机制甚至Full GC。我见过不少人把这个参数调到20%以上想减少Full GC结果是白费内存。预留比例过大相当于实际可用堆变小了反而增加GC频率。保持在10%即可真正的关键是把IHOP控制好让老年代在Mixed GC期间维持足够空间。并发线程参数通常是两个一起看-XX:ParallelGCThreads并行GC线程默认按CPU核数推导和-XX:ConcGCThreads并发标记线程默认约为ParallelGCThreads的25%。在容器化环境下JVM可能识别错CPU数导致线程数过高。如果容器限了4核而JVM识别为16核并发标记线程会占满CPU影响业务线程。建议在容器启动参数里显式设置-XX:ParallelGCThreads4 -XX:ConcGCThreads2如果是8核以上的物理机ParallelGCThreads可以保留默认值不必手动干预。3. ZGC的适用边界什么时候真的应该换掉G1ZGC是低延迟场景的产物核心目标是让GC停顿时间维持在10ms以内并且停顿时间不随堆大小线性增长。但ZGC并不是免费的午餐它的代价是更高的CPU开销和更复杂的内存管理。选择ZGC本质上是拿CPU换延迟。3.1 ZGC的工作模型着色指针、读屏障与并发转移ZGC的关键机制可以概括为三点着色指针Colored Pointers、读屏障Load Barrier和并发转移Concurrent Relocation。着色指针利用64位指针的高位存储标记信息在读指针时通过读屏障判断对象是否被移动从而在不暂停应用线程的情况下完成对象转移。说实话读屏障带来的开销是实打实的。在ZGC下每次从堆中读取引用都需要额外判断这会导致CPU开销比G1高出约10%~20%。对于低延迟系统这点开销值得对于吞吐量敏感的批处理系统这是纯浪费。另一个重要变化是ZGC没有传统意义上的分代结构JDK 21开始分代ZGC转正但默认仍推荐不分代方案对象生命周期无法利用朝生夕灭的特性。这意味着即使对象很快死亡ZGC也会对包含它们的页面做较重的标记处理。对于短生命周期对象占主导的应用ZGC的并发标记成本偏高。3.2 用数据判断停顿时间、CPU成本与堆容量的真实关系ZGC最适合的场景是堆内存大至少16GB以上、对单次GC停顿极度敏感、应用能容忍CPU开销上升。如果你的服务堆内存只有2~4GB用ZGC就是在浪费CPU对分配速率很高、对象存活时间极短的场景ZGC可能不如G1合适。我整理过一个判断矩阵绕开各种概念直接用业务特征对号入座业务特征更适合的收集器判断依据堆内存16GB以下容忍100ms级停顿G1ZGC的CPU开销大于收益堆内存大但CPU核数紧张G1ZGC并发阶段会抢CPU要求10ms级停顿大堆CPU有富余ZGC停顿时间几乎与堆大小无关对象存活率极高老年代非常稳定ZGCG1的混合回收收益很低批量计算、吞吐优先G1吞吐优先场景ZGC没有优势这里的判断核心在于ZGC的停顿时间不随堆增大而恶化但CPU开销相对稳定地偏高。所以只有当堆足够大、业务对停顿足够敏感时ZGC的优势才能盖过它的劣势。3.3 不适合ZGC的情况小堆、高分配速率与CPU敏感场景我见过有人把ZGC直接用到4GB堆的网关服务上结果Young阶段的分配压力让读屏障频繁触发整机CPU上升了25%延迟并没有明显下降。原因在于小堆本身就撑不了多少分配压力ZGC的并发处理被高频分配鞭打GC线程一直处于忙状态。高分配速率的场景也要慎重。ZGC的并发转移和标记速度快但读屏障是每次引用访问都执行的低层逻辑。分配速率越高业务线程访问引用次数越多读屏障累积开销越明显。这时候把分配速率降下来比换任何收集器都有效。CPU敏感场景需要额外说明容器环境下如果CPU限额有限ZGC的并发线程需要抢CPU时间片业务线程会出现处理器调度延迟。这时即使GC停顿很低整体接口RT也可能升高。遇到这类情况先用top -H -p pid看看GC线程CPU占比如果超过15%就要评估ZGC是否划算。4. 从告警到落地的完整调优流程一次真实案例的复盘前面讲参数和理论这一节我用一个虚拟但绝对典型的案例串一遍从发现问题到参数落地的完整过程。案例背景某在线查询服务高峰时QPS约5000堆内存设置为16GB运行在8核16GB的容器上业务对单次请求的P99延迟要求在200ms以内。4.1 现象与数据收集从告警信息定位问题根源某天监控告警老年代使用率持续超过85%P99延迟从120ms飙升到450ms同时出现Full GC记录。我先拉取GC日志看到最后几次关键GC节点[Full GC 11281.234s][GC Worker Total 6.234s, GC Worker Max 6.230s] [Eden: 2048M(2048M)-0B(2048M) Survivors: 128M-128M Heap: 15.8G(16G)-14.2G(16G)]Full GC耗时6.2秒这在线上完全不能接受。堆回收后仍然占用14.2GB富余空间连10%都不到。这说明老年代里大量对象长期存活G1的Mixed GC已经拿不回空间了。结合JFR数据我定位到某接口会一次性加载配置表全量数据到内存并缓存4小时。配置表数据量大、加载频率偏高导致大量对象长时间存活。4.2 参数调整与验证为什么这样设置而不是那样设置这个案例表面上像是GC参数问题实际是缓存策略堆水位问题。我做了两件事第一代码侧把缓存T从4小时降到1小时并改为按需分页加载降低单次分配总量。这是真正的治本措施。第二JVM参数上做配合调整。堆16GB、默认Region约8MB没有改Region大小的必要。我把-XX:G1HeapWastePercent从5%降到3%让Mixed GC更积极同时设-XX:G1MixedGCCountTarget16增加单轮混合回收的次数让回收更平缓。这里说明一下为什么调这两项缓存对象量大单个Region的存活率差异很大降低“垃圾占比阈值”会让更多低价值Region参与回收而增加回收轮次则避免一次回收太多Region导致停顿过高。等待日志确认时我开启了GC日志并按老年代水位画了一条趋势线。调整后四个小时的曲线从一路爬坡每次只降一点变成锯齿规律下降Full GC消失P99稳定在130~150ms。4.3 效果对比与后续观察测量驱动的调优习惯调优完成后我习惯做两个维度的对比一是GC维度观察Mixed GC的频率、单次耗时和回收量二是业务维度观察P99延迟和错误率。这里给出调整前后的关键对比指标调整前调整后Full GC频率每40分钟1次0Mixed GC平均耗时750ms260msGC后老年代水位14.2GB10.1GBP99延迟450ms140msCPU平均使用率68%55%值得注意的是CPU使用率反而下降了。原因是Full GC抢占了大量CPU调整后并发标记和混合回收的节奏更合理整体线程调度也平滑了。这类对比数据应该保留在每一次调优记录里后续做容量评估和参数回归都非常有用。5. 参数之外那些没人写进文档的GC调优习惯与避坑经验如果说G1参数是术那调优习惯才是道。很多问题不靠参数而靠排查路径和经验判断来解决这部分内容我打算直接写操作中连续踩过几次坑才总结出来的要点。5.1 参数组合优于单个参数不要迷信某一条神参数我经常看到有人把MaxGCPauseMillis从默认的200调成50然后发现GC更频繁就认定G1没用。真正的问题是参数之间是联动的停顿目标变短年轻代被压缩晋升率升高老年代更快堆积IHOP被频繁触发并发标记又被压缩……整个系统陷入恶性循环。调参的基本逻辑是先看堆水位再调节奏最后微调目标。顺序错了效果往往适得其反。以G1为例我的调参顺序是先确认堆大小是否合理-Xms和-Xmx设为相同值避免运行时堆扩容。观察老年代水位和Mixed GC频率确定IHOP方向。再调MaxGCPauseMillis让停顿时间跟业务容忍度对齐。只有上面三步走了仍不理想才动G1ReservePercent、G1MixedGCLiveThresholdPercent这些细粒度参数。这个顺序能避免大部分参数改动引发的次生问题。5.2 自适应机制与手动设置何时应该关闭G1UseAdaptiveIHOPG1的G1UseAdaptiveIHOP在稳定负载下表现很好但如果应用内存使用率天天大起大落自适应IHOP会不断调整并发标记触发点导致回收节奏混乱。判断方法很直接看GC日志里并发标记周期之间的间隔是否规律。如果间隔忽长忽短且Mixed GC后老年代水位反弹很快手动关闭自适应往往更稳。关闭后需要手动设置-XX:InitiatingHeapOccupancyPercent。具体值可以根据历史GC日志推算观察Full GC前老年代的最低水位然后在此基础上降低5~10个百分点。例如Full GC前老年代最小是12GB堆16GB那么IHOP可以设在70%11.2GB留足时间给并发标记完成。5.3 压测与灰度发布没有流量验证的调优等于空谈调完参数不上压测直接上线是在赌运气。我见过把MaxGCPauseMillis从200调到50后测试环境一切正常、上线后直接雪崩的案例。区别在于线上的真实分配速率和对象存活模式与压测数据差距很大。稳妥做法是先在压测环境用真实流量回放跑至少一版观测GC日志和P99延迟灰度发布时先放10%流量确认稳定后再逐步放量。每次变更只改一个参数或一个代码因素否则出问题根本定位不到原因。5.4 版本选择同一个参数在不同JDK版本的行为差异G1和ZGC在不同JDK版本上行为差异非常大。比如JDK 11的G1在Region回收策略上明显不如JDK 17优化充分ZGC在JDK 15之前不支持分代JDK 21以后分代ZGC才正式可用。如果你的应用是老版本JDK照抄新版本博客的参数会翻车。如果条件允许建议至少升级到JDK 17再谈GC调优。新版本自带的改进往往比调几个参数更有效。ZGC更不用说分代ZGC在JDK 21开始默认不启用但支持用之前必须确认版本。6. 从G1到ZGC的迁移路径判断依据与操作步骤很多人看完ZGC的优势就想直接迁移但实际工作中从G1切换到ZGC更像一次小型的架构变更。最后这一节我讲讲迁移前要做哪些准备以及切换后应该盯哪些指标。6.1 迁移判断的量化标准什么时候值得动手在真正切ZGC之前我会先做一个量化评估分三个维度给分堆内存应用常驻堆在16GB以下ZGC收益不明显不建议迁移。32GB以上ZGC有明显优势。停顿目标G1在现有参数下无法稳定低于100ms且排除了代码层面的问题后才考虑ZGC。CPU余量容器或物理机在高峰期CPU平均使用率低于70%ZGC并发工作才有资源空间。三个条件都满足才动手。只满足一个或两个的先继续把G1调好。实际操作上切换ZGC只需要改两个启动参数-XX:UnlockExperimentalVMOptions -XX:UseZGCJDK 15以后不需要UnlockExperimentalVMOptions直接-XX:UseZGC即可。6.2 切换后的重点观测项不只看GC停顿还要看CPU与线程调度切换到ZGC后很多人只盯着GC日志里的停顿时间发现确实在10ms以内就觉得大功告成。但ZGC的并发行为会改变整机的CPU和线程调度模式尤其要注意下面三个指标第一GC线程CPU占比。ZGC的并发标记、并发转移和并发重定位都会长时间占用CPU。如果占比超过20%且业务RT反而上升说明CPU余量不足迁移失败。第二内存分配速率与页面碎片。ZGC在分配对象时使用64位着色指针堆内存内部是页面默认2MB管理。如果分配以超大缓冲为主页面的对象存储效率会下降表现为堆内存占了但回收效率不高。第三线程停顿分布。用jstat -gcutil观察每轮GC周期的时间分布ZGC的停顿极短但整体GC周期可能拉长到几十秒。如果你看到单次GC周期耗时40秒但期间业务无感知这就是ZGC的正常行为不用担心。我在一次实际迁移中还遇到过一个不在常规文档里的细节ZGC下大对象分配引发的页迁移会导致一个CPU核心长时间忙于搬运数据。这时候把-XX:ConcGCThreads适当调小把并发工作分散到更多核心上反而能让整体延迟更稳定。6.3 迁移后回退方案没有退路的迁移是不完整的每次涉及收集器的变更都必须准备回退方案。我的做法是保留整份旧启动脚本和旧版本镜像新版本上线后持续观察至少一周确认GC停顿、P99延迟和CPU三个维度全部达标才移除旧配置。如果中途发现ZGC导致CPU压力过高回退G1不是简单换回启动参数就行的。G1的Region布局和ZGC的页面布局不同回退时最好直接发布旧版本镜像而不是在运行中动态切换。运行中切换Shenandoah或G1JVM会执行一次完整重置带来的STW反而比正常GC还可怕。7. 几个容易误判的场景用真实经验帮你少走弯路GC调优的错误判断很多时候不是参数问题而是对现象的理解出了问题。这里写三个我反复见过的误判每个都对应一条如果重来会怎样处理的复盘。7.1 误判一把系统CPU飙升错怪GC实际是真内存泄漏某次线上CPU飙到90%GC日志显示频繁Full GC团队第一反应是GC参数有问题。我看了JFR后发现某类对象数量在半小时内从5万涨到600万显然是内存泄漏导致老年代持续暴涨才诱发Full GC。GC只是背锅根源是缓存Map的key没有清理。这种情况调任何参数都没有意义。正确做法是用jmap -dump抓堆快照再用MAT分析支配树找到占内存最大的对象路径。GC调优的边界就是当堆使用率直线上升且永不回落时先查泄漏再谈调优。7.2 误判二ZGC停顿为0但接口RT长时间波动ZGC把GC停顿降到了3ms以内但接口的P99反而从120ms涨到180ms。排查后发现瓶颈不在GC而是ZGC的读屏障增加了CPU指令数8核容器满载后线程调度延迟上升。把容器扩到12核后P99立刻回落到110ms。这个案例说明ZGC的低停顿是有代价的代价就是CPU和内存带宽。迁移前必须确认CPU有富余否则只是把GC延迟问题转移成了调度延迟问题。7.3 误判三无脑调大堆内存以为能解决一切堆内存从8GB调到32GBYoung GC频率确实降低了但Mixed GC单次耗时从200ms涨到800ms业务直接超时。因为堆变大后并发标记和全堆扫描的对象基数也变大了。多数场景下堆内存应该匹配业务对象总量和分配速率而不是越大越好。如果堆内存大但对象存活率低反而建议控制在合适范围。判断依据是堆使用率长期低于20%说明堆配大了GC后堆水位持续高于80%说明堆可能偏小或存在存活率异常。两种极端都不健康。8. 最后的经验小结GC调优是持续迭代的过程GC调优不是一次性任务而是一个需要持续迭代的过程。每次版本发布、依赖升级、流量模型变化都可能让之前的参数变得不再合适。我个人会定期检查GC日志把Full GC次数、Mixed GC平均耗时和堆水位三个核心指标记录成趋势表一旦发现数据偏离基线就主动介入分析。在各环境中保持相同的JVM参数也是一件容易被忽略的事。经常有人测试环境用G1、生产环境却用了默认的并行GC导致压测数据完全不具备参考价值。JVM参数应该作为应用配置的一部分纳入版本管理和代码一起评审、一起发布。如果你刚开始接触GC调优我建议先别急着动参数把GC日志和JFR的运行习惯养好。工具和数据到位后参数调整只是顺水推舟的事。最后分享一个我自己的习惯每次调优后都会在变更记录里写清楚调了哪个参数、基于什么现象、预期什么结果、实际什么结果。几个月后再看这些记录就是最宝贵的经验库。