1. 先搞清楚调优的方向GC日志到底能告诉你什么1.1 调优之前必须建立的三个基本认知先说结论JVM调优最核心的输入就是GC日志。没有日志支撑所有的参数调整都是盲猜调对了是运气调错了是常态。我见过太多人上来就改堆大小、换垃圾收集器结果线上 gc 频率没降多少反而把停顿时间拖长了。要避免这种情况你必须先建立三个基本认知。第一个认知GC日志不是性能报告而是事件流水账。每一行GC日志只记录一次垃圾回收事件它告诉你什么时候发生了回收、回收了多少内存、用了多长时间。这些零散的事件拼合起来才能还原出JVM内存使用的真实面貌——比如老年代在什么业务时段持续增长、新生代对象晋升速率有多快、Full GC是不是伴随着某个接口的调用峰值。所以分析日志的第一步永远是把零散记录聚合成趋势而不是盯着一两条日志死磕。第二个认知参数优化是决策不是照抄配置。网上流传的各种最佳实践参数模板本质上是在一个特定场景下验证过的结果换到你的业务模型里可能完全失效。比如一个以读为主、对象朝生夕灭的Web服务和一个处理大文件、批量任务的数据管道两者的内存分配模型截然不同适合的 GC 参数也必然不一样。你要做的是理解每个参数背后的权衡逻辑然后根据自己日志里暴露的痛点是频率高、停顿长还是吞吐低去选择对应的调整方向。第三个认知调优靠数据说话不靠直觉。不管是判断要调大新生代还是该换G1每一条决策都必须有日志数据支撑对象晋升速率是多少Survivor区有没有频繁溢出每次GC的平均耗时和中位数是多少这些指标才是指挥棒。后面我会拿出一套完整的实操流程演示怎么从日志数据一步步推导出该改哪个参数。1.2 常见垃圾收集器的工作特性与选型判断GC日志格式和使用方式跟JVM当前用的收集器强相关。在看日志之前你得先确认自己的JVM用的是什么收集器。这里我按使用频率从高到低讲一下主流收集器的日志差异。Parallel Scavenge / Parallel OldJDK 8 的默认组合关注吞吐量。它的新生代日志格式是 PSYoungGen支持使用 -XX:UseParallelGC 主动启用。Serial单线程收集器日志格式是 DefNew常见于客户端模式或小堆场景。ParNew CMSJDK 8 时代互联网公司很常见的组合日志格式是 ParNew年轻代 CMS老年代。它的日志里特别值得关注的是 CMS-initial-mark、CMS-concurrent-mark 和 CMS-concurrent-abortable-preclean 这几个阶段任何 concurrent mode failure 都意味着老年代回收跟不上对象分配速度。G1JDK 9 的默认收集器日志以 garbage-first heap 或 G1 Evacuation Pause 开头。它的调优维度和传统分代收集器差异很大重点看 Mixed GC、Region 分配和 Humongous 对象。ZGC超低停顿方向日志以 ZGC 开头关注的是 ZGC 各阶段的并发时间占比一般用于超大堆场景。从日志识别当前收集器是最快的路径启动时加 -XX:PrintGCDetails然后看GC日志第一行跟哪个名字能对上。这个信息决定了你后续哪些参数有意义。比如你在 G1 上调整 -XX:NewRatio它虽然认这个参数但实际效果远不如调 -XX:G1NewSizePercent 来得直接。在 Parallel 上设置 -XX:G1HeapRegionSize 则完全无效因为那个参数只对 G1 生效。所以我的习惯是拿到一个线上JVM第一步永远是拿到启动参数确认收集器版本和关键配置第二步才是找一段覆盖业务峰值时段的GC日志做分析。顺序不能反否则分析半天可能是在给错误的收集器对症下药。2. 读懂GC日志从格式到含义的完整拆解2.1 一次Young GC日志逐行解读现在拿一条平行收集器的典型Young GC日志来做拆解。启动参数是 -XX:PrintGCDetails 时输出的就是这种格式[GC (Allocation Failure) [PSYoungGen: 61440K-8928K(61440K)] 61440K-12032K(197632K), 0.0215876 secs] [Times: user0.04 sys0.01, real0.02 secs]拆开来看GC表示这是一次Minor GC。如果是Full GC说明老年代或元空间也参与了回收。(Allocation Failure)触发原因说明是新生代分配对象时内存不足。这是最常见的触发因素意味着年轻代已经填满了。PSYoungGen新生代回收前后存量格式是回收前大小-回收后大小(该区域总大小)。61440K-8928K(61440K)GC前用了60MB回收后剩8.7MB但总容量还是60MB。回收后没到0说明有部分对象存活。61440K-12032K(197632K)整个堆的回收前后和总大小。整堆从60MB降到11.7MB总大小是193MB。这里要注意堆总大小是新生代容量老年代容量但不同收集器对Survivor区的口径有差异。0.0215 secsSTW停顿时间这是小停顿的核心指标。0.02秒的停顿对大部分业务可以接受但如果这个值持续超过0.2秒就要警觉了。Timesuser是用户态CPU时间、sys是内核态CPU时间、real是真实耗时。多线程回收时 real往往远小于 user因为回收工作被多个GC线程并行执行了。如果 user/sys 很低而 real 很高多半有CPU竞争或IO抖动。再看一条G1的日志格式差异就比较明显[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0236124 secs] [Parallel Time: 21.0 ms, GC Workers: 8] [Eden: 56.0M(56.0M)-0.0B(44.0M) Survivors: 8192.0K-12.0M Heap: 64.0M-18.0M(256.0M)]G1关注的字段是Eden 区收缩量、Survivor 区变动和整堆回收前后的变化。如果你在日志里频繁看到Humongous Allocation或G1 Humongous Allocation说明有大对象超过Region一半大小频繁分配这在大对象扎堆的场景下很致命。2.2 Full GC日志特征与危险信号Full GC的日志与Young GC差异明显重点表现在整个堆都参与了回收[Full GC (Metadata GC Threshold) [PSYoungGen: 8192K-0K(9216K)] [ParOldGen: 255M-190M(256M)] 263M-190M(265M), [Metaspace: 127M-127M(128M)], 0.5138210 secs]这条日志里有几个危险信号元空间触发 Full GCMetaspace 从127M塞到127M总大小128M。这种情况在动态生成类的应用里很常见解决方向是调大 -XX:MaxMetaspaceSize或者排查是不是类加载器泄漏。老年代从255M降到190M回收后仍占用74%这说明老年代中存活对象比例高新生代晋升过来的对象密度大。耗时0.5秒这已经是明显影响线上接口RT的水平。如果 Full GC 持续超过1秒说明堆内存压力已经到临界点。另一个高频危险信号是CMS 的 concurrent mode failure[GC (Allocation Failure) [ParNew: 6144K-6144K(6144K), 0.0123456 secs][CMS: 10240K-10000K(10240K), 0.5433212 secs]看到 ParNew 回收后数量没变6144K-6144K紧接着 CMS 又用了0.54秒做老年代回收这就是 CMS 并发回收跟不上新生代晋升速率的结果。遇到这种情况光调新生代大小没意义得考虑给老年代留更大空间或者降低晋升速率比如调大 Survivor 比例甚至考虑换 G1。2.3 利用jstat实时查看GC状态GC日志是事后分析但很多线上排查场景需要即时数据。jstat 是我最少不了的命令没有之一jstat -gcutil 12345 1000 20这个命令每秒输出一次进程12345的GC利用率共输出20次。输出的S0、S1、E、O、M分别代表两个Survivor区、Eden区、老年代和元空间的使用占比YGC和FGC是累计回收次数GCT是累计回收总耗时。我常用的排查套路是先执行上面这条看当前各区占比和GC频率再叠加业务的请求量指标。如果发现老年代占比从20%一路涨到80%且不回落就算 YGC 次数不多也基本可以确认有对象在持续进入老年代下一步才需要 dump 堆找是谁的问题。jstat 输出的最大优势是实时无侵入线上直接敲命令就能看不像 JFR 需要录制和分析适合做快速判断。3. 参数优化的核心逻辑从日志数据反推参数3.1 用日志指标反推优化方向日志读懂了参数优化就有了依据。优化的本质其实是围绕三个目标的平衡低停顿、高吞吐、低内存占用这三者在绝大多数场景下不可兼得。我的判断框架是这样的如果GC频率过高Young GC每秒好几次但单次停顿很短说明堆太小或者新生代太小可以考虑整体调大堆。如果单次停顿过长说明单次回收的对象量太大需要缩小单次回收规模比如调小新生代、增大 Survivor、或者换并发收集器。如果Full GC 频率高优先排查内存泄漏和对象晋升而不是急着加内存。如果吞吐量不达标GC总耗时占业务运行时间比例过高优先考虑大堆 Parallel 模式它天生为吞吐优化。举个具体的计算例子假设日志里统计出1小时内发生了120次Young GC每次平均耗时0.02秒同时有2次Full GC每次平均耗时0.5秒。那么 GC 总耗时是 120×0.02 2×0.5 2.4 1.0 3.4秒占整小时的0.094%。从吞吐角度看99.9%的算力都花在业务上这种情况完全不需要调优。但如果你的业务的P999耗时因为那两次1秒的Full GC而从80ms涨到1.2秒那问题就是停顿而不是吞吐。有一个我常用的经验值线上服务的 Young GC 频率控制在每10秒一次以内、单次停顿低于50msFull GC 一天不超过几次且单次不超过200ms基本就不需要过多干预。超出这个范围再动手不迟。3.2 关键参数作用与计算示例这里把高频使用的参数整理成速查表参数作用指导原则-Xms / -Xmx初始堆/最大堆生产建议设成一致避免扩容抖动-XX:NewRatio老年代:新生代比例默认2对象生命周期长可调大-XX:SurvivorRatioEden:Survivor比例默认8晋升频繁可调大-XX:MaxMetaspaceSize元空间上限防止元空间无限扩张和Full GC-XX:UseG1GC切换G1收集器JDK9默认大堆优先-XX:MaxGCPauseMillisG1软目标停顿时间指导性参数非硬性限制-XX:ParallelGCThreadsGC并行线程数默认与CPU核数相关不易过度调大-XX:HeapDumpOnOutOfMemoryErrorOOM自动dump必开参数别等OOM后抓瞎给一个具体的计算过程。线上服务堆内存定为4GB日志显示 Young GC 每5分钟一次老年代占比却缓慢上升。我把 -XX:NewRatio 从默认的2调成3之后新生代从约1.33GB降到1GB老年代从2.67GB升到3GB。表面上看新生代小了应该更频繁GC但由于老年代多了空间Full GC 被推迟了。这就是典型的用老年代的余量换取 Full GC 的频次下降。再看 Survivor 区调整。默认 Eden:Survivor 8:1:1假设新生代1GBEden约819MB每个Survivor约102MB。如果日志里出现大量对象从Survivor晋升到老年代在Full GC日志里看到老年代增长曲线陡峭说明存活对象超过Survivor的容量。把 SurvivorRatio 调成6Eden降到768MBSurvivor升到128MB晋升少了Full GC 自然也少了。这种微观调整对降低 Full GC 频率效果显著。3.3 不同场景的参数配置模板不同业务模型的参数模板差异很大我按场景给出三套常用模板供你在此基础上根据实际日志微调。Web服务吞吐优先响应延迟敏感4-8GB堆JDK8 Parallel-Xms4g -Xmx4g -XX:NewRatio2 -XX:SurvivorRatio8 -XX:UseParallelGC -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.log大堆服务16GB堆追求可控停顿JDK11G1-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis100 -XX:G1NewSizePercent5 -XX:G1MaxNewSizePercent60 -XX:PrintGCDetails -XX:PrintGCDateStamps低延迟网关/中间件追求低停顿JDK17ZGC-Xms8g -Xmx8g -XX:UseZGC -XX:ZCollectionInterval2这三套模板的核心差异在于Parallel 用频繁但快速的新生代回收换吞吐G1 用可预测的停顿模型换平滑的延迟表现ZGC 用并发回收把停顿压到毫秒级。搞清楚你的业务更怕哪种性能劣化再选对应的模板比直接抄参数靠谱得多。4. 完整实操一次JVM调优的现场记录4.1 问题描述与初步排查有一次帮朋友排查他们的订单服务业务高峰期接口P99耗时从80ms飙到900ms链路追踪里看到大量请求卡在服务内部但数据库响应正常。初步怀疑JVM停顿立刻拿 jstat 看实时状态发现老年代利用率已经到92%且频率很高。于是拉取当时的GC日志缩小排查范围2019-08-12T10:24:31.2090800: 3721.456: [GC (Allocation Failure) [PSYoungGen: 61440K-6272K(61440K)] 61440K-34832K(197632K), 0.0256112 secs] [Times: user0.05 sys0.01, real0.03 secs]Young GC后整堆依旧占用34MB老年代持续增长。10秒后出现Full GC2019-08-12T10:24:41.7720800: 3731.019: [Full GC (Ergonomics) [PSYoungGen: 6144K-0K(61440K)] [ParOldGen: 196608K-130048K(197632K)] 202752K-130048K(197632K), [Metaspace: 10240K-10240K(10240K)], 0.5321871 secs]Full GC 耗时0.53秒老年代回收后仍有130MB占比高达66%。这说明问题不在JVM参数本身而是有大量对象在持续进入老年代且无法释放。4.2 日志深度分析与定位过程把 GC 日志导入 GCViewer统计一个小时内的数据Young GC 平均每40秒一次耗时稳定在20msFull GC 每20分钟一次耗时500ms。Full GC 频率远高于健康水位。再用 jmap 做堆转储jmap -dump:formatb,fileheap.bin 12345用 Eclipse MAT 分析后发现一个订单缓存 Map 对象占据了堆内存的42%。根因是缓存系统在高峰时段对订单状态做了全量拉取但缺少过期机制大量订单状态对象无法被GC回收。这一步是重点参数调优不能解决代码层面的对象生命周期管理问题。参数再合理对象还在那里堆着老年代还是会涨满。遇到这种情况先把代码逻辑修正再回头评估JVM参数是否需要动。4.3 参数调整与效果对比代码修正后我做了如下参数调整目标是扩大新生代以容纳更多短期对象、降低 Young GC 频率堆大小从 192MB 提升到 512MB-Xms512m -Xmx512m该服务是轻量级订单服务512MB 足够承载峰值流量保持 NewRatio2使新生代约170MBSurvivorRatio 从8调成6加大Survivor容量降低晋升开启 HeapDumpOnOutOfMemoryError为后续兜底。调整前后效果对比如下指标调整前调整后Young GC频率约90次/小时约15次/小时Full GC频率约3次/小时约0.5次/小时Full GC平均耗时531ms120msP99耗时高峰期900ms110ms调完参数后持续观察一周Full GC 频率没有再回升P99 稳定在100ms左右。这次调优总结下来80%的收益来自代码修复20%来自参数优化。参数优化是放大器方向对了它放大效果方向错了它放大故障。5. 常见问题与排查技巧实录5.1 高频故障场景速查表实际工作中线上 JVM 问题基本跑不出下面这几类。我做了一个速查表排查时先对照确认方向现象可能原因优先排查方向Young GC次数持续暴涨堆太小 或 Eden区过小jstat确认Eden占比调大年轻代Full GC频繁且每次回收比例低老年代存活对象多/内存泄漏jmap dump MAT找占用大头Full GC后老年代立刻又涨满对象晋升过快Survivor太小调大SurvivorRatio降低晋升单次GC停顿时间很长堆太大回收范围太大换G1/ZGC或调小单次回收目标Metaspace触发Full GC动态生成类过多/泄漏调大MaxMetaspaceSizedump分析GC后CPU占用持续飙升GC线程竞争或并发标记CPU竞争检查GC线程数设置观察并发阶段时间显示不友好难对应业务日志没开日期戳加上 -XX:PrintGCDateStampsOOM时没留下任何线索没开dump参数必加 -XX:HeapDumpOnOutOfMemoryError每个方向背后都是独立的排查链路这里不再展开但有一句话值得强调凡是遇到参数调优解决不了的内存问题先回到代码层面找对象生命周期管理的问题。JVM调优的首选策略永远是少制造垃圾其次才是把垃圾收拾得更快。前者靠代码后者靠参数。5.2 踩过的坑和避坑心得第一个坑生产环境忘了加 -XX:PrintGCDateStamps。默认的GC日志时间是很不友好的相对时间戳3731.019这样的JVM启动秒数要把这个数字对应到业务具体的时刻得先换算启动时间非常痛苦。后来我把这个参数列入了新项目启动模板的必选项还加了 -XX:PrintGCDetails没有这两个参数就不要谈后续分析。第二个坑调了 -Xmx 忘了调 -Xms。JVM运行中从初始堆向最大堆扩容是需要开销的扩容过程本身就伴随STW这在堆从512MB往4GB扩张的场景下表现特别明显。生产环境一定把两个值设成一致宁可初始就大一些不要让JVM在运行中频繁扩缩容。第三个坑GCViewer 导出的数据不是越多越好。刚接触GC日志的人喜欢统计所有时间段的数据结果把一次发布带来的日志混进了一天的数据里GC频率被平均得毫无参考价值。分析前先按业务发布节点切割时间窗口只分析某个稳定运行时段的数据。我习惯看峰值时段单独一段、全量时段单独一段否则平均值会掩盖真实问题。第四个坑只看平均值不看P99。有一次调完参之后GC平均停顿从100ms降到了60ms看起来很成功。后来一细看分位数才吓一跳P99停顿有700ms。平均值的欺骗性就在这GC日志分析一定要看分布至少拆出P50、P90、P99。5.3 常用工具链推荐最后整理一下我常用的工具清单给入手JVM调优的朋友一些参考jstatJDK自带适合快速查看实时GC状态零侵入。jmap堆转储和查看堆配置的标准工具注意在堆内存紧张的时候执行会加大压力线下场景可以用 jhsdb 替代。GCViewer开源的GC日志图形化分析工具适合看趋势统计粒度和图表都很方便。新版建议直接用在线版的 gceasy.io图表交互更友好但注意日志上传前脱敏。Eclipse MAT堆转储分析利器能直接给出最大对象的保留链内存泄漏定位用它效率最高。JFR JMCJDK 11 的飞行记录器。比起GC日志它能额外看到线程、IO、锁等更多维度当你怀疑问题不在GC而在应用自身时就用它做全维度诊断。工具终归是辅助底层逻辑才是核心先确认目标低停顿还是高吞吐再计算偏差现在离目标差多少最后动参数用日志验证效果。写在最后从最早被线上突发Full GC搞得焦头烂额到现在能相对从容地通过日志定位问题我个人的体会是JVM调优没有什么神秘的高深理论它更像一门门槛不高的手艺活。只要肯花时间把日志格式吃透、把每个参数背后的权衡想明白、再积累几轮调整后观察-记录-再调整的实战循环大部分业务场景的性能瓶颈都能被有效控制。如果只让我留一个建议那就是每次调整只改一个参数改完用日志验证对比前后趋势再动下一个。很多人喜欢一次性给JVM换血式地调五六个参数出了问题根本分不清是谁的锅。一次只改一个虽然看起来慢反而是最快的路径。这轮分享就到这里。希望下次你再看GC日志的时候每一行都像读电报一样清晰。如果这篇文章帮你少走了一个坑那它就值了。