在讲GC调优之前，我想先分享一次让我印象很深的调优经历。当时接手一个模拟项目X的中间件优化，业务方反馈线上接口P99延迟持续走高，GC日志显示Young GC非常频繁。我第一反应也跟大多数人一样——直接把堆从4GB调到8GB，同时把G1的RSet相关参数压了一遍。结果出乎意料：Young GC频率确实降下来了，但接口延迟反而更差了。因为堆变大以后，对象晋升行为完全改变，老年代在短时间内就被打满，紧接着触发了更吓人的Full GC。后来做了对象分配分析才发现，是某个缓存工具类没有设置过期时间，把大量本应短命的对象长期钉死在堆里。改掉这个代码问题之后，GC参数完全恢复默认，应用自己就安静了。
这个案例让我重新审视了一件事：大部分时候我们以为自己在做GC调优，其实调的根本不是GC，而是业务代码分配内存的方式。所以这篇文章我不会一上来就给你一堆参数，而是想用更贴近实战的方式，把GC策略、算法选型、目标设定、调参步骤和避坑清单系统性讲清楚。无论你是刚接触JVM的新人，还是维护过上百个服务实例的资深开发，这里的内容应该都能带给你一些可落地的参考。
1. 先别急着调参数：把GC问题当成“症状”而不是“病因”
GC调优不是万能的。如果你把GC问题当成了病症本身，那你只会一直给JVM开止痛药，永远找不到真正的病灶。我见过太多团队拿着网上流传的“最佳参数模板”直接套到生产环境，然后得出“调了也没用”或者“换了G1反而变慢”的结论。问题往往出在起点上。
1.1 优先排除的几类代码级问题
以下这类问题如果存在，不管你调什么GC参数，效果都很有限：
无意义的对象分配。循环体里频繁创建临时对象，尤其是字符串拼接、包装类型转换、反复分配的容器对象。这类问题最容易被忽视，因为它对功能没有影响，但对分配速率影响极大。识别方法很简单，看GC日志中的分配速率和晋升速率，如果分配速率很高但实际存活对象很少，说明大量对象是“昙花一现”的。
缓存无边界。本地缓存或HashMap没有设置上限、过期时间、淘汰策略。这种代码对堆内存的压力是缓慢而持续的，通常表现为老年代占用率稳步爬升，最终在某个高峰时段触发Full GC。
连接和句柄未释放。数据库连接、网络连接、文件句柄泄漏，本质上就是对象生命周期管理失败。这类问题的GC特征和缓存问题不同，它更集中在特定时间点，比如连接池耗尽之后。
我个人的习惯是：在调整任何GC参数之前，至少先用jstat -gcutil连续采集24小时数据，再配合GC日志中的分配速率和晋升速率做初步分类。如果是“分配太多”，优先级在代码侧；如果是“回收太慢”，才轮到参数侧介入。
1.2 真正需要GC调优的场景清单
排除代码问题之后，以下场景才是GC参数真正应该发挥价值的地方：
- 堆的大小规划与物理资源不匹配。比如物理机有64GB内存，JVM默认只用了1/4，而业务负载确实需要更大的堆。这种情况下，合理调大堆就能立竿见影。
- GC算法的停顿特征与应用需求不匹配。比如低延迟服务在使用默认配置的G1时，偶尔会出现超过200ms的停顿，而业务要求P99不超过100ms，这时就需要调整GC节奏或换用更低延迟的回收器。
- 需要满足明确的停顿时间SLA。比如规定了单次GC停顿不能超过100ms，你就需要针对不同代际、不同区域的回收节奏做更细的配置。
- 由监控数据驱动的精细化调优。比如通过分析发现Survivor空间频繁溢出导致对象提前晋升，或者大对象区域分配过多，这类数据驱动的调整才有实际意义。
只有上述情况，你的时间和精力投入在GC调优上才是划算的。否则，回到代码层面排查和优化，性价比高得多。
2. 堆内存结构与GC算法选型：先弄清你在和什么打交道
想调好参数，底层逻辑是要先理解“GC在管理什么”。堆内存的逻辑划分很简单：Young区、Old区、元空间。但不同GC算法处理这些区域的方式差异非常大，同样的参数在不同算法下表现可能截然相反。
2.1 堆分区的生命周期规律与常见推论
JVM堆可以拆分为四个逻辑区域：
| 区域 | 用途 | 生命周期特征 |
|---|---|---|
| Eden | 新对象分配 | 绝大多数对象在这里出生并快速死亡 |
| Survivor S0/S1 | 幸存者缓冲 | 对象经历Minor GC后在此区域来回交换 |
| Old | 长期存活对象 | 对象晋升后进入，回收频率远低于Young区 |
| Metaspace | 类元数据/常量池 | 独立于堆，类加载与卸载决定其增长和回收 |
对象的正常路径是：从Eden出生，经历一次Minor GC后如果存活，进入Survivor；每经历一次GC且存活，年龄加1；到达阈值或Survivor空间放不下时，晋升到Old区。
基于这条基本路径，有几个非常容易被忽略的推论：
- Survivor空间过小，会导致活对象在Young GC时直接晋升到Old区，表面上老年代增长变快，实际根源在Survivor配置不当。这个问题比“Young区太小”隐蔽很多。
- 年龄阈值不是固定15。不同回收器、不同参数下动态年龄判定会改变实际晋升年龄，所以GC日志里经常看到晋升年龄不是15的现象。
- 大对象不走Eden。在G1中，超过Region大小一半的对象直接进入Humongous区域，等于直接跳过Young区回收。如果系统频繁创建大数组或大缓冲，这块内存只能靠并发标记周期回收，节奏完全不可控。
理解了这些规则，你才能解释为什么某些参数调整会带来“反直觉”的后果。
2.2 主流GC算法的特征对比与适用场景
当前JVM可用的主流GC算法，按历史演进可以分成几个梯队：
| GC算法 | 核心思路 | 优势 | 劣势 | 典型适用场景 |
|---|---|---|---|---|
| Serial | 单线程串行回收 | 实现简单、无线程切换开销 | 停顿长、多核CPU利用率低 | 单核小内存、开发调试环境 |
| Parallel | 多线程并行回收 | 吞吐量优先、回收效率高 | STW时间长、延迟不稳定 | 批处理、计算密集型任务 |
| CMS | 并发标记清除 | 低停顿、并发回收 | 内存碎片化严重、CPU占用高、已废弃 | 存量老系统、未升级JDK的项目 |
| G1 | 分区式垃圾优先 | 可预测停顿、吞吐和延迟较均衡 | 大堆下Mixed GC可能较长 | 服务端通用默认、中大规模堆 |
| ZGC/Shenandoah | 染色指针+读屏障 | 停顿时间极短、支持超大堆 | 内存开销大、并发阶段吞吐略降 | 超低延迟要求、大堆场景 |
这里想多说一句：GC算法的选择不只是性能问题，也是维护成本问题。CMS在JDK9被标记废弃、JDK14移除，继续守着CMS的项目会越来越孤立。如果系统没有明确的兼容性门槛，我建议新项目直接用G1或ZGC，老项目也要规划迁移路径，而不是在CMS上继续投入深度调优。
2.3 一个切合实际的算法选型决策过程
算法选型不能只看“延迟敏感”还是“吞吐优先”这种抽象标签，要落到量化需求上。举例说明，某个模拟批处理系统每天凌晨处理海量数据，白天提供查询服务。如果只用单进程承载，白天需要低延迟，凌晨需要高吞吐，这两个需求本质上是冲突的。比较合理的设计是白天进程用G1承载在线请求，凌晨单独起一个Parallel进程处理批量任务，再在编排层把资源分离开。
具体做选型决策时，我通常问自己三个问题：
- 业务对P99和P999的响应时间预算分别是多少？如果要求在几十毫秒内，ZGC或Shenandoah才有意义；如果预算在100到200毫秒，G1调优就够用了。
- 堆预期有多大？如果堆超过16GB且追求低停顿，G1是底线，ZGC优势更明显。
- CPU核数是否充裕？ZGC和Shenandoah的读写屏障会带来额外开销，核数不足时吞吐损失会被放大。
3. 明确调优目标与指标度量：不要用“感觉”指导GC优化
GC调优最怕的就是没有量化目标。很多团队的“调优”就是从网上找参数抄一遍，然后看线上不那么卡了就认为成功。这种模糊的验证方式既不严谨，也无法沉淀成可复用的经验。
3.1 吞吐量、延迟、内存占用：GC调优的三维坐标
真正值得量化的性能指标有三个，它们构成一个“不可能三角”：
| 指标 | 定义 | 调优方向 |
|---|---|---|
| 吞吐量 Throughput | 非GC时间占总运行时间的百分比 | 减少GC总耗时，让有效计算时间更多 |
| 延迟 Latency | 单次请求从发起到完成的时间 | 降低单次停顿时间、降低停顿频率 |
| 内存占用 Footprint | JVM堆及相关元数据占用的物理内存 | 控制堆在合理范围，避免过度分配 |
堆越大，GC频率越低，但单次停顿和物理内存开销可能上升；追求极低停顿，通常需要额外的内存和CPU；追求最高吞吐的Parallel GC，延迟完全不可控。所以你不能同时把三维都做到最优，必须接受业务需求决定了优化优先级这一事实。
以交易支付链路为例，如果业务要求P99响应时间小于150ms，那么调优目标就是让绝大多数GC停顿落在极短范围，同时不接受过于频繁的GC导致CPU空转。反过来，如果业务目标是“每天批处理能在凌晨4点前跑完”，调优方向就变成“吞吐量优先”，停顿时间只要不导致宕机就行。
3.2 完整的数据采集方案：GC日志、jstat与监控告警
调优必须建立在完整数据之上。我建议至少采集以下三块：
- GC日志。JDK8及以前版本可以这样配置：
java -Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50MJDK9及以后的统一日志系统更简洁：
java -Xlog:gc*=debug:file=/path/to/gc.log:time,level,tags:filecount=10,filesize=50m日志里必须包含时间戳和堆使用量信息，这样后续才能按时间轴联动业务峰值和GC行为。
JVM统计信息。
jstat -gcutil <PID> 1000可以按秒打印GC及堆占用概览。连续采集至少24小时，不要只看一两分钟的数据。外部监控。把GC次数、GC耗时、堆使用率、Full GC次数接入监控大盘，并配置告警。我自己常用的一组初始告警线是：每分钟Young GC次数超过某个阈值，或者单次Full GC时长超过200ms就告警。具体阈值因业务而异，但必须有。
3.3 基线与变更记录：让每次调参都有对照
调优不是一次性动作，最好是“基线—变更—验证”闭环。每次只改一组参数，记录变更前后的指标对照。举个例子：
| 指标 | 调优前 | 第一次变更后 | 第二次变更后 |
|---|---|---|---|
| Young GC平均停顿 | 25ms | 18ms | 15ms |
| Full GC次数/天 | 12 | 3 | 1 |
| P99响应时间 | 240ms | 190ms | 177ms |
| GC总时间占比 | 2.1% | 1.5% | 1.2% |
这张表不仅方便你验证本次变更是否有效，还能在团队评审或后续排障时作为客观依据。调优过程中最忌讳只凭“感觉快了”或“感觉稳了”来下结论。
4. 逐步调优操作框架：从初始参数到逐项验证
掌握了目标和数据采集方法之后，下面进入实操环节。我要强调的顺序是“从稳到精”，先把基础规划好，再逐项微调，避免一上来就堆参数。
4.1 第一步：合理规划初始堆与最大堆
很多团队在-Xms和-Xmx上吃过亏。要么两者不一致导致JVM频繁扩容缩容堆，间接引发GC时长波动；要么-Xmx设得很大而-Xms很小，启动后堆慢慢扩展，峰值时期才暴露出问题。
对于在线服务类应用，我通常建议一致设置：
-Xms8g -Xmx8g好处非常明确：启动时一次性申请到位，避免运行期扩容；堆尺寸确定后，JVM内部区域划分和阈值计算更稳定；避免了容器环境下物理内存与最大堆之间的叠加风险。
初始值到底定多少，经验方法是先观察稳定运行时的峰值堆占用，在这个基础上留20%到30%的余量。不要拍脑袋选32GB。如果业务峰值只有8GB，你把堆调到32GB，GC频率确实下降，但每次GC扫描的区域更大，停顿可能反而恶化。
4.2 第二步：校准Young区与Survivor区
在G1中，Young区是动态调整的，不像传统分代那样直接通过-Xmn固定。但在调参之前，你仍然需要先分析“新对象分配速率”和“晋升速率”。
如果Young GC频率高，但每次GC后存活对象很少，晋升比例低于10%，说明Young区可以适当增大，或者增大Survivor占比。如果Young GC频率不算高，但每次晋升量很大，往往说明Survivor空间不足，或者对象生命周期比预想的长，此时应该回到代码层排查，而不是单纯调大Young区。
对于G1，有两个参数可以限制Young区的动态范围：
-XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60这两个参数设置了G1调整Young区的上下界。默认情况下G1会根据停顿时间目标自行调整，如果你发现Young区的自动调整过于激进，导致吞吐下降，或过于保守导致Young GC频繁，就可以适当收紧上下界。
4.3 第三步：设置合理的停顿时间目标
G1有一个核心参数-XX:MaxGCPauseMillis，很多人的理解是“设置后GC停顿不会超过这个值”，这是错误的。它真实的作用是让G1根据预测模型不断调整区域大小和回收节奏，去“努力接近”这个目标。
如果你把这个值设成1ms，JVM会把大量计算资源花在调整区域和规划回收上，最终不仅目标达不到，吞吐量还会明显下降。我建议从100ms开始设，结合业务延迟预算逐步调整。记住，GC停顿的SLA要和真实业务挂钩，而不是追求无意义的极限数字。
4.4 第四步：处理大对象和显式GC
大对象在G1中会直接进入Humongous区域，而Humongous区域的回收依赖并发标记周期，无法在普通Young GC中处理。如果你的服务频繁分配大数组，很容易造成GC节奏失控。
处理方向有三个：
- 代码层拆分或复用。把常用的大数组池化，或者改用流式处理，减少一次性大块内存分配。
- 调整Region大小。
-XX:G1HeapRegionSize可以设置Region尺寸，默认JVM根据堆大小自动选1MB到32MB。如果Humongous分配频繁，可以试试点调大Region来改变大对象的判定阈值。 - 显式GC必须处理。
System.gc()在线上几乎就是毒药，CMS下直接触发Full GC，G1下默认也是Full GC。如果确实无法避免调用，至少加上-XX:+ExplicitGCInvokesConcurrent，把它转成并发周期，而不是Full GC。
4.5 第五步：用工具辅助分析，而不是盲调参数
日志分析工具有很多，我的习惯是分级使用：
| 工具 | 适合场景 | 使用体验 |
|---|---|---|
| GCViewer | 快速概览GC次数和时间分布 | 老牌稳定，适合单机分析 |
| GCeasy | 在线分析，自动给调优建议 | 方便直观，适合起步阶段 |
| VisualVM / JMC | 实时查看堆、CPU、线程 | 适合运行期采样与对象分配分析 |
标准化流程一般是先导出GC日志，用GCeasy或GCViewer看几个关键视图：平均GC耗时、GC频率随时间变化曲线、GC后的堆占用曲线。锁定问题区间后，再看是否需要导出Heap Dump分析具体对象引用链。
5. 通用调优策略与高频误区：哪些动作有效，哪些是自欺欺人
5.1 投入产出比最高的调优动作排序
基于多个实战项目的经验，按投入产出比排个序：
- 消除不必要的大对象分配。收益最大，有时只需要改几行代码。
- 合理规划堆大小并保持-Xms与-Xmx一致。收益大，风险极低。
- 选对GC算法。G1或ZGC按需选择，一次改动长期受益。
- 调整MaxGCPauseMillis目标。影响G1等可预测停顿算法，需结合观测结果持续迭代。
- 调整Survivor比例或晋升阈值。效果精细但风险高，需要分析晋升速率后再动。
- 调整Region大小或GC线程数。多数场景不需要，调错反而降低性能。
5.2 高频误区清单
以下误区在我的观察中反复出现，每一条背后都有具体案例支撑：
- 误区一：堆越大越好。大堆降低Young GC频率，但扫描范围变大可能导致单次停顿更高。典型症状是调大堆之后，Full GC间隔变长但单次Full GC时长反而上涨。
- 误区二：调低MaxGCPauseMillis一定能降低停顿。停顿模型是预测性的，目标远低于实际能力时，G1会为了“接近目标”不断调整行为，结果GC频率上升，目标仍未达成。
- 误区三：看到Full GC就认为是GC参数问题。Full GC的诱因可能是堆满、大对象过多、元空间不足、显式GC调用。定位的时候要先用
-XX:+PrintGCDetails看各区域占用，再决定方向。 - 误区四：照抄社区“成功配置”。JVM参数极度依赖场景。同一个参数在8核16GB订单服务上有效，迁移到2核4GB网关服务上很可能起反作用。
- 误区五：忽略容器环境。容器里JVM默认的MaxHeapSize可能基于宿主机内存计算，而不是容器配额。如果不显式设置
-Xmx，很容易因为超出容器内存限制被强制杀掉。
5.3 一个调优前后的完整对比案例
为了让思路更直观，这里构造一个模拟项目X的调优过程：
初始状态：8核16GB机器部署查询服务，运行默认G1。线上观察到每分钟约15次Young GC，平均停顿11ms；每10分钟出现一次14ms左右的并发标记停顿；夜间批处理时段每天有8到10次Full GC，单次最长480ms。
排除代码问题后：先记录基线，再用VisualVM观察对象分配，确认每小时存在较多一次性大数组分配约64MB，属于业务高峰期的读操作，代码侧暂难优化。
参数调整步骤：
- 堆调整：
-Xms4g -Xmx4g。 - 调整Young区上下界：
-XX:G1NewSizePercent=8，-XX:G1MaxNewSizePercent=50。 - 调整停顿目标：
-XX:MaxGCPauseMillis=80，先观察两天再决定是否继续。 - 监控Humongous区域分配占比，确认大对象压力稳定后才继续后续动作。
最终效果：Young GC频率下降一半以上，夜间Full GC基本消失，P99延迟从220ms降到155ms，GC总停顿时间占比从2%降到1%左右。
6. 调优节奏与长期维护：调完一次，不代表一劳永逸
关于调优的工作节奏，最后分享两点心得。
第一，一次变更，充分观察。单独调整一个参数，至少用连续24小时的监控数据来验证。因为短时间观察会被业务波动掩盖，连续变更多个参数后出现问题，根本没法定位是谁引起的。我经历过一次为了赶上线，同时调整了堆大小、GC算法和日志级别，结果上线后出现性能抖动，排查了整整一天才定位到是堆大小变更引发的连锁反应。
第二，把调优当作持续工作。业务流量结构会变化，新功能会带来新的对象分配模式，堆容量和GC算法如果始终不变，性能迟早会退化。一个可行的做法是每个版本迭代后，快速看一眼GC日志，确认没有新的异常增长点。
最后一个实操建议：调优完成后，把完整的参数基线、变更记录、指标采集方式沉淀到团队知识库。三个月后的版本迭代，当你需要回看当时的决策动机时，会发现这些历史记录比任何调优文章都有价值。GC调优最大的挑战从来不是技术参数本身，而是你是否能清晰地说出“为什么这么改”。
