JDK17刚发布那阵子，有个老同事翻出一份Java 8时代的调优参数文档，往启动脚本里一粘，程序直接起不来。这事儿当时让我印象很深：JDK17的GC调优，其实已经不是大多数人习惯的那套玩法了。默认回收器换成了G1，CMS被彻底移走，ZGC从实验室走向生产，日志参数全面迁移到统一的Xlog体系——如果不重新理解和梳理这些变化，沿用JDK8那套经验很容易踩坑。
这篇文章想把这几年在JDK17上做GC调优的实践拆开来讲，重点不是背参数，而是帮你建立一条从"现象观察"到"方案落地"的清晰路径。如果你正被老年代回收频繁、Full GC随机打断服务、或者RT突然拉高这些问题困扰，又不想盲目百度一堆互相矛盾的参数，这篇文章应该正好对你有用。
1. 为什么JDK17的GC调优是一道新题
1.1 从CMS消失开始的生态变化
很多人对垃圾回收的认知还停留在"Serial、Parallel、CMS、G1"这四个经典选型上。JDK8时代，稍微讲究一点的团队都会用CMS，理由也很简单：并发标记清理，低停顿，对在线服务友好。但从JDK9开始默认回收器换成G1，JDK14彻底移除CMS，到了JDK17，你如果还想在启动脚本里写-XX:+UseConcMarkSweepGC，JVM会直接报"Unrecognized VM option"，连启动都过不去。
这意味着网上大量基于CMS调优的文章，在JDK17环境里基本失去了参考意义。JDK17里可选的回收器其实还有几个：Serial、Parallel、G1、ZGC、Shenandoah，另外还有一个专门做基准测试和极端低内存场景的Epsilon（不回收垃圾）。CMS对应的那套老参数，比如CMSInitiatingOccupancyFraction、UseCMSCompactAtFullCollection，在JDK17里全部失效。
更值得关注的是ZGC。ZGC在JDK11还是实验特性，到JDK15转正，到JDK17已经是可以放心上生产的版本。它能把GC停顿压到极低，这在旧时代几乎不敢想象。所以JDK17的GC调优，与其说是在旧参数框架里修修补补，不如说是一个全新的决策空间：你首先要想清楚用哪个回收器，然后才谈得上怎么调。
1.2 主流回收器在JDK17下的定位
我在JDK17下做技术选型时，习惯先用一张表把几个回收器的特点框住：
| 回收器 | 目标 | 典型停顿 | 适合场景 | JDK17状态 |
|---|---|---|---|---|
| Serial | 单线程、简单 | 较长 | 小型应用、桌面工具 | 保留 |
| Parallel | 吞吐量优先 | 较长 | 批量计算、离线任务 | 保留 |
| G1 | 吞吐与停顿平衡 | 10~200ms区间 | 大多数在线服务 | 默认 |
| ZGC | 尽量压低停顿 | 通常<10ms | 大堆、低延迟服务 | 转正可用 |
| Shenandoah | 并发压缩、低停顿 | 通常几十ms以内 | 中大型堆、延迟敏感 | 转正可用 |
选择逻辑并不复杂：如果你的服务对延迟不敏感，比如跑批任务、数据清洗，Parallel往往比G1吞吐更高；如果是一个常规Web接口服务，追求吞吐和延迟的平衡，直接用默认G1；如果堆内存动辄二三十GB以上，又希望接口的尾延迟不被GC打断，ZGC基本是首选。
我曾经帮某团队看过一个案例，他们的服务堆内存设到了64G，业务线对P99延迟要求又特别高，一开始沿用JDK8的G1参数，结果老年代回收时停顿经常冲到300ms以上。后来切换到ZGC，P99从150ms降到80ms左右，CPU只多消耗了大约8%。这类收益在G1上是很难靠调参拿到的。
1.3 调优思路必须跟着GC模型变
很多人对GC调优的理解是"搜几个参数，抄到启动命令里"，但JDK17的环境下，这么做风险更高。原因是G1和ZGC的回收模型比CMS复杂得多，比如G1引入了Region、记忆集（Remembered Set）、并发标记周期、混合回收（Mixed GC）等机制，光靠一两个参数根本控制不住整体行为。
所以正确思路应该是先做观测、再定目标、然后做最小干预。JDK17提供了很完整的可观测性工具，GC日志的粒度可以精细到每个阶段耗时，JFR（JDK Flight Recorder）甚至能记录每一次垃圾回收的分配速率、晋升速率和停顿明细。用好这些数据，往往比盲目改参数更能解决问题。
2. 调优前必做：目标、观测与工具链
2.1 先把调优目标量化
我遇到很多人一上来就问：G1的MaxGCPauseMillis应该设多少？IHOP调到多少合适？这种问法其实反了。没有明确的可量化目标，调参就是碰运气。
GC调优本质是在回答三个问题：分配速率高不高、对象存活率怎么样、回收成本能不能接受。你至少需要定义三个指标：GC停顿目标（比如一次GC不超过100ms、P99不超过50ms）、GC频率上限（比如每分钟Young GC次数不超过10次、Full GC完全不出现）、吞吐底线（比如应用于GC之外的有效运行时间占比不能低于95%）。
举个例子，一个在线订单服务，业务方明确要求接口P99在100ms以内，那GC停顿目标就可以定到50ms以下，因为GC停顿只是RT的一部分，还要留余量给网络和业务计算。反过来，一个离线报表任务，T+1跑完就算成功，你完全可以把GC目标定义成"吞吐最高"，选Parallel更合适。
2.2 启动阶段就把观测能力打开
生产环境最怕的是出了问题才发现日志没开。JDK17里建议把GC日志、堆转储、JFR这些能力默认打开，而且最好做成标准配置模板。我个人的经验是，直接用这段基础参数兜底：
-Xlog:gc*:file=/data/logs/gc/gc-%t.log:time,uptime,level,tags:filecount=10,filesize=50m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/gc/heapdump.hprof -XX:+ExitOnOutOfMemoryError这段参数的含义是：GC详细日志写入文件，按时间和大小滚动保留；一旦发生OOM就输出堆快照；并且JVM直接退出，方便上层调度系统及时拉起新实例。ExitOnOutOfMemoryError这个参数很多人不熟，它比单纯的HeapDump更进一步，防止进程在堆耗尽后继续半死不活地硬撑。
JFR在JDK17里也可以直接生产开启，预留的运行时开销非常低。启动时加-XX:StartFlightRecording=duration=60m,filename=/data/logs/gc/monitor.jfr，然后用jfr print命名事件，能看到每次GC的所有阶段耗时。这套组合下来，排查问题时基本不用靠猜。
2.3 日常观测四板斧
说到运行时观测，我最常用的工具依次是：
- jstat：看GC趋势最稳。
jstat -gcutil <pid> 1000 30可以连续观察30秒内Eden、Survivor、老年代的占用比例以及GC次数和时间。 - jhsdb jmap：看堆里对象分布和内存占用。
jhsdb jmap --heap --pid <pid>能得到当前堆的分区情况（jmap在JDK17的部分场景下不如jhsdb稳定，这是个坑）。 - JFR事件：看单次GC的阶段性耗时，例如jdk.G1GarbageCollection事件里会列出"young collection"和"root region scan"等细分阶段。
- 外部指标：如果服务接入了监控体系，重点盯GC Pause时间、GC次数、堆使用率三个大盘指标。
有一个非常容易忽略的点：分配速率比堆占用更重要。老年代缓慢增长可能是正常业务，如果分配速率突然飙升，即使堆还有空闲，也会很快触发GC。用JFR的jdk.ObjectAllocationSample事件能看到哪些栈分配了大量对象，九成情况下都能定位到某个热点的集合操作或大量临时字符串拼接。
3. G1调优：参数地图与每个参数背后的原因
3.1 G1的Region模型，决定你不能乱调参数
G1把整个Java堆划分成一个个相等大小的Region，每个Region在逻辑上可能是Eden、Survivor或老年代。回收时G1优先挑垃圾最多的Region（垃圾优先，Garbage First），通过并发标记找出回收收益最高的区域，再通过混合回收来一步步搬家。
这个设计带来的调优哲学和CMS完全不一样：CMS调的是老年代几时触发并发标记、预留多少空间；G1调的是停顿目标、回收步幅和并发标记节奏。如果你还拿固定-Xmn去写死新生代大小，G1的自适应能力会被大大削弱，等于让一个自动档汽车手动挂死档位。
3.2 G1的关键参数表与调整思路
下面这组参数，是我在JDK17下做G1调优最常用的，每个都写明了调整思路：
| 参数 | 默认值 | 作用 | 什么情况下需要动 |
|---|---|---|---|
-Xms/-Xmx | JVM自行扩展 | 堆初始/最大 | 生产必须设为相同值，避免运行时扩容/缩容带来的停顿 |
-XX:MaxGCPauseMillis | 200 | G1的软性停顿目标 | 目标过低（如50ms以下）会让G1频繁计算并大幅压缩新生代，反而增加GC次数 |
-XX:G1HeapRegionSize | 自动 | Region大小 | 有明显的大对象且尺寸贴边时可以考虑调整 |
-XX:InitiatingHeapOccupancyPercent | 45 | 触发并发标记的堆占用阈值 | 偏低会导致并发周期频繁，偏高会导致回收赶不上分配 |
-XX:G1NewSizePercent | 5 | 新生代下限 | 限制新生代不被压缩得过小 |
-XX:G1MaxNewSizePercent | 60 | 新生代上限 | 限制业务临时对象过少时新生代膨胀 |
-XX:G1ReservePercent | 10 | 预留空间 | 经常出现转移失败（Evacuation Failure）时调大 |
-XX:G1MixedGCCountTarget | 8 | 混合回收分几轮完成 | 混合回收单次停顿太长时调大，让回收更分散 |
-XX:ConcGCThreads | 自动 | 并发标记线程数 | CPU核数少或受竞争严重时适当压缩 |
先说-XX:MaxGCPauseMillis，它是最容易被误解的参数。它不是硬性上限，而是G1预测模型的一个目标。G1会通过历史概率模型估算下一个周期停顿多久，如果发现很容易突破目标，就会主动变小新生代、减少回收区数量，把停顿压到目标以内。目标设得太严，新生代会频繁被压缩，导致大量短命对象直接晋升老年代，老年代压力反而变大。我在实践中看到很多人设成50ms甚至10ms，结果Full GC频次上升，恰恰是调反了。
再说-XX:InitiatingHeapOccupancyPercent（简称IHOP）。不准确的网上资料会说它是"老年代占比阈值"，更准确的理解是：当整个堆的占用比例达到这个阈值，G1就开始启动并发标记周期。默认45%。如果你的服务堆使用率长期只在30%~40%，但老年代回收仍然跟不上，说明IHOP偏大；如果并发标记周期频繁启动，但标记过程中垃圾占比其实很低，说明IHOP偏小。我的经验是先从45%出发，观测一到两周，再根据GC日志里并发周期的时间间隔和停顿数据微调。
3.3 三个特别容易踩的G1参数坑
第一个坑是设置-XX:MaxGCPauseMillis=1或者类似极小的值。G1为了满足这种不可能的软目标，会不断把新生代压小，最后结果可能是Young GC每秒一次，整体吞吐崩盘。如果你是延迟敏感型，不如直接上ZGC，而不是在G1里硬怼停顿目标。
第二个坑是手动固定-Xmn。G1自适应的新生代调节能力很强，硬设新生代会打断它对停顿目标的计算路径。如果你真的觉得新生代偏大或偏小，正确姿势是用G1NewSizePercent和G1MaxNewSizePercent设上下限，给G1一个自由发挥的区间。
第三个坑是-XX:G1HeapRegionSize调得过大。Region越大，并发标记和记忆集维护的粗略程度越高，而且Humongous对象的判定标准和后续回收策略都受影响。只有在GC日志中频繁看到类似"Humongous allocation of large object"的分配时，才考虑让Region变大去“吸收”这些大对象，否则保持默认就好。
4. ZGC与Shenandoah：低延迟GC的另一条路线
4.1 ZGC为什么能把停顿压到极低
如果你被G1的停顿波动折磨得够呛，JDK17里的ZGC值得认真考虑。ZGC的核心思路是：把回收的绝大多数工作都并发化，让业务线程和回收线程一起跑，只保留极少数需要在安全点进行的操作。它用染色指针（Colored Pointers）在指针里存储标记、重映射等信息，遇到引用访问时通过读屏障来处理，不需要像传统回收器那样反复移动大块对象。
在JDK17里，ZGC虽然还没有分代（分代ZGC是后续版本才逐步完善的），但基本能力已经很扎实。大多数实践场景下，ZGC的单次停顿能控制在10ms以内，好一点的负载可以压到1~2ms。对超大堆（几十GB起步）的服务来说，这个收益非常明显，因为G1的Region再多，回收遍历成本也会随堆变大，而ZGC靠并发处理，受堆大小的影响小得多。
启动ZGC很简单：
-XX:+UseZGC -Xms16g -Xmx16g注意ZGC不太吃MaxGCPauseMillis这套老参数，它内部是围绕“尽量减小停顿”设计的，所以不需要像G1那样给它设停顿目标。ZGC的主要代价是CPU。读屏障会在每次引用访问时多做一些事，导致吞吐量比G1低一些，不同场景下可能低5%~15%。如果你们CPU资源本来就紧张，选ZGC前要先想清楚。
4.2 Shenandoah和ZGC怎么选
Shenandoah和ZGC一样，也是并发回收路线，但它采用的是转发指针和读屏障机制，在中大型堆上同样能把停顿控制得很低。JDK17里Shenandoah已经转正，启动方式也是简单的-XX:+UseShenandoahGC。
那到底选哪个？我的个人判断标准是：优先看技术栈和运维熟悉度，其次看负载特征。ZGC的染色指针机制在以后的JDK版本中演进明显，思路更前卫；Shenandoah在某些场景下对分配速率不敏感，但在读多写多的引用访问负载下，读屏障开销要单独测。我没有一个一劳永逸的答案，遇到具体业务都是先做对比压测：同一个服务，分别用G1、ZGC、Shenandoah开三套环境，压一版测试流量，录GC停顿和RT采样，谁的数据好选谁。
4.3 低延迟GC的适用边界
低延迟GC不是银弹。如果你的堆内存本来就很小（小于4G），或者业务是典型的批处理，ZGC带来的收益很微弱，反而多花CPU。我见过一个团队把全部服务都换上ZGC，结果一些低QPS服务出现CPU上涨和吞吐下降，后来又换回了G1。
所以说，选回收器应该像一个工程师选工具，而不是追潮流。判断基准始终是：停顿时长是不是当前服务的核心痛点。如果不是，G1默认就够用；如果是，优先评估ZGC，同时做好CPU预算的评审。
5. 一次基于G1的调优过程复盘
5.1 案例背景与现象
某订单处理服务（以下用代称"某订单服务"），JDK17 + G1，堆初始和最大均为16G，平时RT的P99在50ms左右。上线发布后某天监控报警，P99涨到180ms，同时GC监控面板里老年代回收次数明显增加，甚至出现Full GC。团队第一反应是加机器，但加了两台后P99并没有明显回落。
我介入后先做了三件事：拿GC日志、开JFR采样30分钟、用jstat连续观测。很快从日志里发现两个关键现象：
- Young GC平均耗时30ms，频率每分钟约15次；
- Mixed GC每轮平均耗时200ms，一天出现多次；
- 偶发Full GC，日志里能看到大量"Humongous allocation"和"Full GC (Allocation Failure)"字样。
5.2 根因分析与参数调整过程
看到"Humongous allocation"时，我第一反应是查大对象。用JFR的对象分配采样能看到，某业务接口每次请求都会生成一个约2.2MB的临时数组。默认Region大小是1MB，任何大于Region一半（512KB）的对象都会被当成Humongous对象直接放入老年代，并且不参与G1的复制回收，只能等待老年代回收——这正是老年代GC频次飙升的直接原因。
这个案例里我做了两个层面的处理：
第一步是程序侧优化，把那个2.2MB的临时数组改成池化复用，或者拆成小块结构。这属于治本方案，功能上线后，Humongous分配明显减少。第二步，为了处理剩余散在大对象，把-XX:G1HeapRegionSize从默认的1MB调到4MB，这样原本超过1MB一半但小于2MB的对象不再被视为Humongous，能被G1以普通Region的方式回收。注意，这里不是让G1HeapRegionSize无限变大，只要能让大部分常规大对象落回普通Region区间即可。
同时调整了IHOP，从默认45%升到60%。原因是观测到一个现象：堆整体占用率并不高，大约只有50%，但G1很早就启动了并发标记周期，周期结束后回收到的对象却不多。这说明并发周期有些空转，白白消耗CPU还增加Mixed GC频率。升到60%之后，并发标记周期间隔拉长，Mixed GC次数降下去，CPU负担也减轻了。
5.3 迭代验证与最终效果
参数并不是一次调完的。第一轮我只改了IHOP和-XX:MaxGCPauseMillis，从原来的300ms改成100ms。观察了两天，Full GC确实不再出现，但Young GC频率稍微升高，Mixed GC偶发停顿还在。
第二轮又把-XX:G1HeapRegionSize从默认调到4M，同时把-XX:G1ReservePercent升到15，给转移失败留出更多逃生空间。之后P99从180ms回到60ms左右，GC停顿的波动幅度也从原来的300ms区间收敛到100ms以内。
这个案例最想说明的是：调优要分轮次、抓主线。如果一开始就同时改八个参数，出了问题根本不知道是谁造成的。我强烈建议每次只改一个维度，观察至少一个业务低峰+高峰周期再决定下一步。上面这个复盘是基于模拟数据还原的典型调优路径，重点在于流程可复现，具体数值到了你的现场还是要以自己的监控为准。
6. 常见问题与排查技巧实录
6.1 老年代GC频发，第一件事做什么
很多人看到老年代使用率到90%就急着调IHOP。但正确的排查顺序是：先看GC日志里老年代回收原因，是廉价的Concurrent Mode Failure（并发模式失败）还是Allocation Failure（分配失败），再看这段时间的对象分配速率有没有上涨。
我总结过一张速查表：
| 现象 | 常见原因 | 优先处理方向 |
|---|---|---|
| 老年代回收频繁但回收效果大 | 分配速率高、存活对象多 | 检查短命大对象、池化连接是否泄漏 |
| Full GC频繁 | 元空间不足、Humongous分配、晋升失败 | 查看Full GC日志和Metaspace上限 |
| Concurrent Mode Failure | 并发标记跟不上分配速度 | 调高CPU配额、降低IHOP、增加堆 |
| Evacuation Failure | 回收集内对象太多、预留空间不足 | 调大G1ReservePercent、降低回收步幅 |
| Young GC频繁但Eden用量不大 | Eden被压缩过小 | 恢复MaxGCPauseMillis合理值，避免硬压新生代 |
6.2 关于元空间和直接内存的两个隐藏陷阱
元空间是JDK里特别容易拖后腿的一环。JDK17的类元数据有自己的Native内存，如果应用频繁动态生成类，或者用了反射、代理、热部署框架，Metaspace会被撑起来。当接近-XX:MaxMetaspaceSize时，JVM会触发Full GC来回收无用的类元数据。这类Full GC常常被误判为堆问题。务实做法是把-XX:MaxMetaspaceSize设一个观察值，并且在监控里加一条Metaspace使用率曲线。
另一个陷阱是直接内存（Direct Memory）。很多NIO框架消费的是堆外内存，它不走GC，但它会让进程的RSS不断上涨，看起来像内存泄漏。调GC参数对这种问题完全无效，你需要的是排查ByteBuffer分配和释放路径。
6.3 我常用的几个兜底习惯
先亮明我的态度：GC参数能少改就少改，能用默认就用默认。我最常做的其实只有几件小事：
- 堆初始和最大设成相同，关掉运行时堆伸缩；
- GC日志、堆转储、ExitOnOutOfMemoryError三件套常开；
- 用JFR定期抽样，而不是等到事故发生了才去补数据；
- 每次调整只改一个参数，保留完整的变更记录；
- 上线前在压测环境跑一轮，不要让新参数直接上生产。
另外有个细节：JDK11之后，GC日志语法从-Xlog:gc衍生出来的-verbose:gc已经被统一到-Xlog体系，很多老资料里写的-XX:+PrintGCDetails在JDK17中已经不推荐用了。如果你在启动参数里看到用了大量过时参数，建议直接看JDK17官方工具说明里的java命令文档，别再用老旧模板。
说句实在话，单纯靠堆参数解决GC问题，很多时候只是把一个瓶颈挪到了另一个环节。GC调优真正的价值在于：让你搞清楚系统当前的内存分配模式、对象存活特征和回收成本，然后用最小代价让它们匹配起来。比如上面那个案例，真正解决Humongous问题的核心是程序侧改对象大小，参数只是辅助。
我现在做GC配置越来越克制，十个服务里有八个用的是默认G1加基础观测参数，顶多根据实际监控微调IHOP和Region大小。这比十年前人人抄一套"惊天调优参数"的时代健康多了。JDK17给了我们更好的回收器、更好的日志体系、更好的可观测性工具，最该做的并不是疯狂调参，而是把这些观测能力用起来，让数据告诉你该动哪里。
