半夜两点被告警电话叫醒线上服务的CPU Load直接飙满接口P99从50ms涨到900msjstat拉出来一看Full GC每分钟十几次每次STW三四秒。这种场景干过后端的人大概率都经历过第一反应通常是“赶紧优化GC”然后把网上流传的JVM参数一顿复制粘贴重启看效果。运气好能撑一阵运气不好第二天又是同一个坑。做了这么多年JVM性能优化我越来越确认一件事GC优化最核心的问题不是参数怎么调而是你的观测体系和分析方法是否靠谱。调参是最后一公里前提是你已经清楚垃圾是怎么产生的、回收器在做哪些动作、停顿到底打在哪个环节。这篇文章就把我这些年排查GC问题的完整思路整理出来从分代原理讲到日志观测从症状反推根因到G1/ZGC选型实践再到代码层的治本之策希望能帮你摆脱“遇事不决调参数”的困境。适合被Full GC折磨过的后端开发、中间件维护者和SRE同学看完至少能建立一套自己的排查框架。1. GC优化的第一性原理分代模型与停顿来源1.1 堆内存分代和两类GC动作很多人对GC的理解停留在“内存不够了就回收一下”但真正定位问题的时候必须把JVM堆分代模型和GC动作对应起来。JVM堆一般分成新生代和老年代新生代又细分为Eden区和两个Survivor区S0、S1比例通常是8:1:1。大多数对象刚创建时都分配在Eden区Eden满了就会触发一次针对新生代的回收动作这就是我们常说的Minor GC或Young GC。经历过一定次数GC还存活的对象会晋升Promotion到老年代。老年代空间不足时触发的是Major GC或Full GC停顿时间通常比Minor GC长得多。这里有一个特别常见的误解有人以为线上GC压力大就一定是老年代出了问题于是玩命调老年代参数结果压根没看到本质。根据我的经验真正高频出现的往往是Minor GC过于频繁导致的CPU毛刺因为新生代小、分配速率高Eden很快就满了回收器就只能不断做年轻代清扫。老年代的Full GC反而是较低频但杀伤力更大的问题。所以分析GC问题第一步就是先区分你看到的是Minor GC还是Full GC这是一个完全不同的排查方向。1.2 STW与安全点理解停顿的本质GC过程中有一件事是绕不开的就是Stop-The-World。回收器在标记、整理某些阶段时必须让业务线程停在安全点SafePoint暂停所有应用线程这样才能保证对象的引用关系不再变化垃圾回收的结果才是正确的。这段暂停时间就是STW用户感知到的卡顿、超时绝大部分都来自STW。为什么线程不能随时暂停因为JVM需要找到一个引用关系处于稳定状态的位置安全点通常设置在方法调用、循环回跳、异常抛出这类指令上。所以你会看到一个现象GC线程在等业务线程“跑到”安全点如果某个线程正在执行一个超长循环或者一次超大集合遍历迟迟不进安全点前端的停顿时间就会被拉长而GC线程只能干等。排查长STW问题时除了看GC本身的时间还得关注那些影响进入安全点的长任务。这也是为什么GC优化本质上是在两个目标之间找平衡——降低STW的暂停时间同时控制GC本身的总开销和CPU占用两个目标在很多时候是互相矛盾的。1.3 回收器演进每种选择其实都在做取舍JVM里出现的回收器一代接一代本质上就是在吞吐、延迟、内存占用、实现复杂度之间做权衡。很多团队还在用JDK8那么可选的是Serial、Parallel、CMSJDK11之后的主流是G1容器化、超大堆、超低延迟场景下还有ZGC和Shenandoah。我整理了一个对比表回收器核心策略目标适用场景状态Serial单线程简单直接最小化内存占用客户端、小堆、单核可用Parallel多线程并行回收提高吞吐量批处理、科学计算、后台任务常用CMS并发标记清除降低停顿时间中等堆内存的Web服务已废弃JDK14移除G1Region分区可预测停顿延迟与吞吐平衡多核大堆的通用服务默认回收器ZGC并发整理染色指针亚毫秒级停顿超大堆、低延迟场景成熟可用我在实际项目中的选型逻辑很简单如果是后台批处理或者离线任务追求吞吐优先选Parallel如果是面向用户的在线服务堆内存在4GB以上直接用G1如果是超大堆64GB以上且对延迟极其敏感ZGC是更好的方向。CMS就别再往新项目里放了它已经走完了生命周期踩坑成本太高。选错回收器才是最大的浪费我曾经见过一个堆内存8GB的服务跑在CMS上一到业务高峰期就Promotion Failed换成G1之后同样的代码和参数Full GC直接消失调优工作流完全不同。2. 动手调参之前先把GC日志和监控基线建起来2.1 一套适合生产环境的GC日志配置先立个规矩任何GC优化动作都是从完整、可靠的可观测数据开始的。现在有太多人一上来就改JVM参数连GC日志都没开这就像蒙眼开车。不同JDK版本的GC日志参数差异挺大我分别给出配置JDK8推荐的参数组合-Xloggc:/data/logs/gc-$(date %Y%m%d-%H%M%S).log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -XX:PrintHeapAtGCJDK11及以后版本使用统一日志标签体系-Xlog:gc*:file/data/logs/gc-%t.log:time,uptime,level,tags:filecount5,filesize50m这里解释几个关键配置gc*表示输出GC相关的全部日志级别%t会展开为启动时间戳方便区分不同版本的日志文件后面的filecount和filesize指定文件滚动策略不允许一个日志文件一直写到磁盘爆满。很多生产事故就是日志配置不规范导致的次生灾害这点必须提前防住。2.2 日志分析工具链怎么选拿到GC日志只是第一步不可能靠肉眼OpenLog一帧一帧看。我的工作流是快速看趋势用GCViewer本地打开一个GC日志几秒钟生成吞吐量、停顿时间、堆占用变化曲线适合找“是不是有持续增长的趋势”。想要自动化诊断用gceasy.io上传日志后直接给出一份诊断报告常见问题比如分配压力、晋升异常、停顿瓶颈都会标出来适合新手快速定位方向。需要跟业务线程关联分析用JFR/JMCJava Flight Recorder能记录到方法级采样、线程阻塞、对象分配热点比单纯看GC日志更细尤其适合定位“什么代码产生了这些对象”。线上实时排查用Arthasdashboard命令能实时看到内存、GC次数、类加载情况jvm命令直接输出当前各内存区域的使用情况和GC汇总配合heap命令可以紧急拉取堆信息。工具不在多关键是形成一条链路GC日志负责交代回收器在做什么JFR/Arthas负责交代业务代码在做什么两条线一交叉根因基本就浮出水面了。2.3 建立基线分配速率与晋升速率在调整任何参数之前先搞清楚你服务的GC“底盘”是什么样子。两个最核心的量化指标分配速率Allocation Rate和晋升速率Promotion Rate。分配速率指单位时间内新生代分配对象的总量晋升速率指单位时间内从新生代晋升到老年代的对象总量。打个比方你家的垃圾产生速度和需要长期存放的大件物品数量决定了垃圾桶该多大、清运车该多久来一次。如果分配速率极高那么无论怎么调回收器Minor GC都会持续高频发生如果晋升速率很快老年代大概率很快就会被打满Full GC只是时间问题。具体怎么算从GC日志里抓一个时间窗口的数据。G1日志里会看到类似Pause Young (Normal) (G1 Evacuation Pause)的记录里面标了每个Region的回收前后用量。记录两次GC之间Eden区释放的总量除以间隔时间就是这段时间的分配速率。晋升速率同理看两次GC之间老年代占用增长量。把这些指标连续记录几天你会得到一个服务的“正常水位”这就是后续调优的基线。没有基线参数改完都不知道是变好还是变坏。3. 从症状反推根因GC问题排查实战清单3.1 YGC频繁但堆内存看着还够线上最常见的第一类症状Young GC次数非常密比如每秒好几次但整个堆的使用率不高老年代占用也平稳。这时候真正的问题不是堆不够大而是分配速率过高代码在疯狂创建短生命周期对象。我用JFR做过一次对象分配采样发现一个服务大量耗时集中在HashMap.put和StringBuilder.toString上而且都是从日志埋点代码打出来的。业务逻辑打印了一行debug日志日志框架内部做了字符串拼接、日期格式化、Map构建等到真正判断日志级别时发现是infodebug根本不输出——这些对象全白建了。单次量不大但QPS一高分配速率直接拉满。修正方法非常直白先通过JFR采样找到分配热点方法然后做代码层治理比如日志框架不要传String去拼接直接传模板参数让框架在确定需要输出时再格式化。比调GC参数管用得多。3.2 Old GC或Full GC频繁出现的多种可能第二类症状更令人头大Full GC开始规律性出现STW时间动辄几秒。可能性通常集中在3个方向晋升速率太高新生代偏小或者MaxTenuringThreshold设置不合理对象还没死透就被推到老年代。GC日志里能看到老年代用量曲线在Young GC后持续台阶式上涨。老年代真的被大对象撑爆G1下超过Region大小一半的对象会被视为Humongous巨型对象直接分配在老年代会跳过新生代。比如一个10MB的缓存对象频繁创建很快就把老年代干穿而且Humongous区域回收成本很高。Metaspace持续膨胀频繁动态生成类、大量使用反射或者CGLIB代理元空间打满触发Full GC。排查链路应该是先看GC日志确认Full GC前后的内存水位变化是回收完还有大量对象活着还是回收完内存正常释放过一段时间又涨上来然后配合堆Dump分析存活对象构成大型HashMap、ArrayList、线程池队列都是重点怀疑对象最后结合业务模块逐一排除。3.3 CPU飙高伴随长STW时间有一次线上报警CPU 100%但GC次数看起来并不算特别多每次Young GC却要耗时800ms以上。这就不是频率问题了而是单次GC停顿异常。导致单次停顿异常的原因有几个方向分配速率太高导致Eden回收量巨大复制存活对象耗时增加。ParallelGCThreads或ConcGCThreads配置不合理线程数过多或者过少都会影响GC执行的并发效率。业务线程迟迟不进安全点。比如某个线程在做一个超大规模的集合遍历或者执行了一段JIT无法优化的热点代码GC线程等它到达安全点就等了几百毫秒。这种情况我会先用top -H -p pid看线程CPU占用把占用最高的线程ID换算成十六进制再去jstack里找到对应线程栈看它到底执行到哪个方法。如果线程栈显示的是GC线程说明卡在回收本身如果是业务线程就得顺着线程栈去看那个正在执行的业务方法。3.4 一次完整案例从告警到定位的排查链路为了让你直观感受一遍我分享一个最近的真实案例。某会员服务的告警规则是“Full GC次数超过每分钟1次”就触发某天下午连续告警单次Full GC STW达到2.3秒核心接口超时率明显上升。我的排查步骤先拉GC日志确认Full GC触发前老年代使用率已接近100%回收后内存下降有限说明有大量存活对象堆积。用jmap抓了一个堆Dump放到MAT里分析Dominator Tree发现一个ConcurrentHashMap持有将近300万个会话对象占用老年代将近70%的空间。顺藤摸瓜找到业务代码是一个登录会话缓存value设置成永不过期又没有人主动清理。用户量上来之后会话对象只增不减。修复方案是给缓存加上TTL过期策略并做定时清理同时把初始容量设置成合理的估算值避免扩容抖动。全程没有改任何GC参数。恢复之后Full GC彻底消失分配速率直接下降了一个数量级。4. 回收器选型与G1参数调优实践4.1 G1、Parallel和ZGC到底怎么选选型不能靠个人偏好先看业务约束。最近几年我用过的选型判断表如下场景特征推荐回收器原因堆内存低于4GB单机吞吐优先Parallel并行回收效率高无需复杂配置Web服务堆内存4GB~32GB延迟敏感G1Region分区能控制在几百毫秒内停顿堆超过32GB要求STW低于10msZGC/Shenandoah并发整理停顿时间几乎不随堆扩大不可变对象多、超低延迟交易系统ZGC染色指针和读屏障带来的低停顿特性如果你的服务还在老项目上用CMS而且没有精力做完整回归测试我不建议贸然切到ZGC步子太大容易出事。G1是从CMS平滑迁移的最佳路径JDK12以后G1已经非常成熟。ZGC更适合新项目或者有明确低延迟目标、团队有足够性能调优经验的项目。4.2 G1核心参数逐个拆解G1是JDK9之后的默认回收器也是我日常调优中使用频率最高的。它的核心思想是把堆划分成多个大小相等的Region新生代和老年代不再物理连续回收时以Region为单位通过维护一个预测模型来动态调整回收哪些Region最终逼近用户设定的停顿目标。下面这张表是我认为每个做G1调优的人都必须理解的参数参数默认值含义建议-XX:MaxGCPauseMillis200msGC停顿目标软目标不设置过小50ms以下容易导致GC过频-XX:G1HeapRegionSize自动Region大小1MB~32MB堆大的场景可以显式设置为16MB或32MB-XX:InitiatingHeapOccupancyPercent45触发并发标记的堆占用阈值老年代波动大的调高到60~70-XX:G1NewSizePercent5新生代初始占比一般不用动-XX:G1MaxNewSizePercent60新生代最大占比分配速率高的可适度调大-XX:MaxTenuringThreshold15晋升老年代前最大年龄默认即可必要时调到6~10-XX:G1MixedGCCountTarget8一轮Mixed GC分几轮做停顿压力大时增大到16~20摊薄每轮耗时这里要重点纠正一个常见误区MaxGCPauseMillis不是硬性指标G1为了达到这个目标可能大幅缩窄新生代结果是Young GC变得极其频繁吞吐反而下降。我见过有人把这个参数调到30ms结果Minor GC从每秒1次变成每秒10次CPU直接飙满接口延迟反而更高。停顿时间和回收频率之间存在天然的跷跷板关系你要根据业务对延迟和吞吐的实际要求找到平衡点。4.3 一组生产可用的G1参数模板以我常用的一个8GB堆服务为例完整JVM参数长这样-Xms8g -Xmx8g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize16m -XX:InitiatingHeapOccupancyPercent70 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/dump.hprof -XX:ExitOnOutOfMemoryError -Xlog:gc*:file/data/logs/gc-%t.log:time,uptime,level,tags:filecount5,filesize50m逐个解释关键选择-Xms8g -Xmx8g初始堆和最大堆设为一致规避JVM动态扩容带来的性能抖动。动态扩容不仅会触发额外的堆增长开销而且堆容量变化会影响G1的Region分配策略不利于停顿预测。-XX:InitiatingHeapOccupancyPercent70默认值是45意味着堆使用到45%就开始并发标记。对于很多Web服务来说这个阈值太敏感并发标记周期太频繁占CPU。调到70是基于线上观察老年代稳态水位大约在50%~60%留出足够余量又不会触发太晚。-XX:HeapDumpOnOutOfMemoryErrorOOM时自动生成堆Dump没有这一步很多内存问题事后根本无法复盘。-XX:ExitOnOutOfMemoryErrorOOM直接退出进程交给容器编排去重新拉起。这比“进程活着但服务不可用”要好得多——至少负载均衡不会再把流量打到这个垂死的实例上。4.4 参数调优的常规顺序和一个教训每次调优我只建议动一个变量调整后至少观察一天业务周期对比GC频率、STW时间和接口延迟的变化。不要同时开三个参数否则出了问题根本分不清是谁的锅。我在实践中踩过最大的坑是为了追求更低的STW把G1MixedGCCountTarget从默认的8改成了5混合GC每轮回收的Region变多、耗时变长导致高峰期出现了几次超过500ms的长停顿。后来才意识到摊薄回收动作才是降低单次停顿的关键。把参数调回默认值配合调高InitiatingHeapOccupancyPercent给老年代更多缓冲空间反而同时解决了频率和停顿的问题。调参不是堆参数多就一定好而是要让每个参数和当前业务模型匹配。5. 治本之道减少垃圾产生比调任何参数都管用5.1 分配速率才是GC压力的总开关把GC比作城市垃圾清运系统回收器是清运车堆大小是垃圾中转站容量而分配速率就是城市每天的垃圾产生量。你在某一天把清运车换成更大的型号、在中转站旁边多租了几个仓库但垃圾源头不控制第二天垃圾还是会把中转站填满清运车还是得昼夜不停。GC优化的最高杠杆永远在代码层——降低分配速率。有一个粗粒度的换算公式可以帮你建立直觉每秒分配量除以每次GC回收量大致就是每秒需要的GC次数。如果每秒分配100MB对象每次Young GC只能回收80MB那每秒至少需要1次以上的Minor GC。参数调整只能影响每次回收的效率但改变不了“垃圾产生量已经超过回收能力”这个根本问题。5.2 高频分配代码模式与修改方案我在这几年做性能治理时总结了一套出现频率极高的“GC杀手”代码模式碰到基本就是它们字符串循环拼接// 反例循环内 拼接每次都创建新的 StringBuilder 和 char[] String result ; for (int i 0; i 10000; i) { result i; } // 正例显式指定初始容量的 StringBuilder StringBuilder sb new StringBuilder(65536); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();String的底层虽然也会用StringBuilder但每次循环都会新建一个、最后再转成String产生两个对象。10000次循环就是20000个对象还不算底层char[]的分配。这种模式在日志拼接、报表生成、业务规则拼装里到处都是。正则表达式反复编译// 反例每次匹配都重新编译 Pattern boolean matched str.matches(\\d); // 正例复用编译好的 Pattern private static final Pattern DIGIT_PATTERN Pattern.compile(\\d); boolean matched DIGIT_PATTERN.matcher(str).matches();String.matches内部每次都会调用Pattern.compile重新编译表达式而正则编译是CPU和内存双高操作。改成static final Pattern后分配量和耗时都会显著下降。集合扩容导致数组拷贝集合初始容量设置过小不断添加元素到需要扩容时底层数组会重新分配并复制一次。高并发下一个反复扩容的ArrayList可以在短时间内产生大量废弃数组对象。套路是new ArrayList(expectedSize)new HashMap(capacity)在创建阶段就预留好空间。日志参数引发的隐式toString很多日志框架支持模板参数传对象而不是传拼接结果// 反例先执行字符串拼接再判断是否输出 log.debug(order info: orderCache.get(orderId) , user: userService.get(userId)); // 正例参数化日志框架在确认输出时才执行 toString log.debug(order info: {}, user: {}, orderCache.get(orderId), userService.get(userId));第一个例子在debug级别不生效时依然执行了两次查询和方法调用的toString所有中间对象全部白建。第二个例子在日志级别不匹配时参数不会执行toString能避掉大量无意义分配。这类优化对高QPS服务收益明显。还有一个不可忽视的技术逃逸分析。JVM的JIT编译器会分析对象是否逃逸出当前方法如果对象始终在方法内部使用、没有暴露给其他线程或方法之外就可能被分配在栈上或者进行标量替换完全不经过堆。这也是为什么某些代码看似创建了对象但实际GC压力并不大。逃逸分析是JIT自动完成的不用配置但理解它能解释很多“为什么这段代码没产生GC垃圾”的反直觉现象。5.3 业务架构层面池化、分批和淘汰策略除了代码微操作业务架构设计对GC的影响往往更大。第一件事是池化。数据库连接池、线程池、HTTP连接池、对象池都不是可选项而是必选项。单次连接创建涉及Socket、缓冲区、线程上下文对象存活时间长、生命周期管理复杂池化能显著减少这类重对象反复创建。第二件事是分批处理。批量导入、批量重试、定时任务扫表最忌讳一次性把千万级数据load到内存。单次加载的数据越多分配的临时对象越多GC的单次回收压力就越大。正确做法是每次从数据库取固定大小的批次处理完再取下一批让内存的峰值水位平缓而不是锯齿状暴涨。第三件事是缓存必须有边界。无界缓存在流量上升时是内存粉碎机而且很难通过GC参数解决。所有缓存容器都必须设置最大容量、过期时间和淘汰策略同时关注缓存中value的大小。大value不仅缓存本身占用高在G1下还可能触发Humongous分配直接把老年代打成碎片化状态。我自己的习惯是在每次大版本发布后强制看一眼GC曲线的走势把GC次数、STW时间、Full GC频率全部挂上监控看板设置分级告警。GC优化不是一锤子买卖而是一个持续观测、持续治理的过程。参数只是最后一公里的方向盘真正决定车辆状态的是整个观测体系和代码质量。先测量再优化别贪心追求零GC最终目标是GC行为可控、停顿可预测、服务延迟稳定。