JVM调优先诊断后调参：内存溢出与GC频繁定位实战-北京尧图网络

先说结论JVM 调优这件事90% 的时间不是在敲参数而是在定位问题。很多同学一遇到内存溢出或者 GC 频繁第一反应就是改堆大小、换垃圾回收器结果参数调了一轮又一轮服务重启多少次还是照样卡顿甚至直接 OOM 崩溃。我自己的经验是真正花时间的是搞清楚“为什么会变成这样”而不是“怎么改参数让它看起来好一点”。这篇东西不是教科书式的 JVM 原理讲解而是基于实际排障过程中总结出来的定位思路和操作步骤适合正在处理线上 JVM 问题、或者准备系统学习 JVM 调优的同学参考。1. 先分清“内存溢出”和“GC 频繁”再动手1.1 两种症状到底长什么样内存溢出OutOfMemoryError和 GC 频繁是两回事但经常一起出现而且很多人分不清当前系统到底处于哪种状态。我这里有一套快速分辨的方法。内存溢出的标志性特征是直接报异常JVM 明确告诉你堆空间不足、元空间不足、或者无法创建本地线程。日志里会出现java.lang.OutOfMemoryError: Java heap space、java.lang.OutOfMemoryError: Metaspace、java.lang.OutOfMemoryError: unable to create new native thread这些字眼。这种情况基本已经“病入膏肓”再谈什么调优参数意义不大第一件事是先把现场保住把 dump 抓下来。GC 频繁则是另一种样子服务没有报 OOM但响应时间明显变长CPU 使用率飙升监控曲线出现锯齿形。你用jstat看一眼会发现 Young GC 几秒钟一次甚至 Full GC 频繁到每秒都在执行但系统又没挂。这种状态是“慢性病”不致命但非常难受业务响应变慢、吞吐量下降影响面非常大。实话说线上最容易翻车的是第二种情况。因为 GC 频繁不会直接把服务打死大家只会觉得“好像有点卡”等到你开始优化的时候问题已经持续很久了。你先得通过监控和日志确认当前到底是哪种状态后续的诊断策略完全不同。1.2 定位顺序先看日志再抓现场后做分析我自己比较习惯的排查顺序是这样的第一步看 GC 日志。如果线上环境已经开了 GC 日志强烈建议生产环境必须开直接看最近一段时间的 GC 日志统计 Young GC 和 Full GC 的频率、停顿时间、晋升情况。GC 日志会告诉你一个大概方向是年轻代满了导致频繁 Minor GC还是老年代持续增长导致 Full GC 频率上升。第二步抓现场。如果条件允许先抓堆 dumpjmap -dump:live或者jcmd GC.heap_dump再抓线程状态。抓的时候要快因为问题可能稍纵即逝尤其是 OOM 的场景JVM 挂掉之后很多东西就没了。现场数据是整个定位过程最值钱的资产。第三步做分析。用 MAT 或者 JProfiler 打开 dump 文件看支配树、找最大对象、查 GC Root 引用链。判断是内存泄漏还是单纯内存分配过大。如果确认是内存泄漏再去代码里找对应的问题点。第四步才是考虑调参数。把根因解决掉之后再根据实际的分配速率、对象大小、存活区情况去调整堆大小、代际比例、GC 器选型等。顺序反了调参永远调不干净。提示先诊断后调整先定位后优化。这个顺序一旦反过来99% 的人会在参数迷宫里越走越远。2. 现场取证GC 日志配置与 dump 抓取2.1 GC 日志参数怎么配以及怎么读我记得有个生产事故排查到最后发现线上环境根本没开 GC 日志故障现场完全靠猜浪费了整整一个下午。所以第一件事就是确认 GC 日志有没有开。没开的话这个事故还没结束就得先把日志补上下次再有问题才有据可查。常见的参数配置是-Xloggc:/path/to/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintHeapAtGC如果是 JDK 11统一用下面的写法-Xlog:gc*,gccausedebug,gcagetrace:file/path/to/logs/gc.log:utctime,pid,tid,level注意几个点。PrintGCDetails会输出具体的分代信息比如 Young GC 之前年轻代占了多少、之后还剩多少。PrintGCDateStamps是把时间戳打上去这个很有用方便和业务高峰时间做对比。另外强烈建议加一行-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump让 JVM 在 OOM 的时候自动把堆现场拍下来这是最省事也最保险的 dump 获取方式。我看了不下几十份线上 GC 日志真正的读法是第一列看 GC 原因第二列看 GC 类型然后看前后内存变化和耗时。比如[GC (Allocation Failure) [PSYoungGen: 130048K-13158K(151552K)] 196471K-79772K(502784K), 0.0058750 secs]这行日志的意思是Young GC 是因为分配失败触发的年轻代从 130MB 降到 13MB整个堆从 196MB 降到 79MB耗时 5.8 毫秒。这种日志频繁出现一次才多长时间如果你看到 Full GC 的耗时是几百毫秒甚至几秒那业务卡顿就说得通了。2.2 抓 dump 的几种常用姿势GC 日志只能说明现象回答不了“到底是什么对象占满了堆”这个问题。想要回答这个问题必须看堆里的对象。最常用的是jmapjmap -dump:live,formatb,file/path/to/arthas-heap.hprof pid注意-dump:live和-dump:all的区别。live只 dump 存活对象文件小、分析快适合快速看当前哪些对象活着all是全量堆包含垃圾对象你要排查“垃圾回收后仍不释放”的问题时用all更完整。但all文件可能很大线上环境要谨慎别把磁盘写爆了。jmap在 JDK 8 之后属于“受诊断”工具有些环境的权限会限制。备选方案是jcmdjcmd pid GC.heap_dump /path/to/heap-dump.hprofjcmd在这个场景下更友好因为它走的是 JVM 的 Diagnostic Command 通道不受 attach 权限限制的场景更多。另外如果用了容器或者无法直接 attach 的部署方式可以把-XX:HeapDumpOnOutOfMemoryError和 dump 路径先配好JVM 会在 OOM 时自动生成 dump这也是最可靠的兜底方案。还有一种情况系统还没到 OOM但是 GC 异常频繁。这种时候我会先抓两到三个堆 dump间隔 10 秒左右。对比不同时间点的 dump看某个集合类、业务对象数量是不是在持续增长。如果连续两个 dump 里某个自定义对象数量翻倍那基本可以锁定泄漏了。2.3 快速定位工具jstat 和在线诊断实际操作中我不可能每次都登录到容器里去敲命令。很多时候系统会监控到Full GC 频繁的告警但问题是间歇性的等我上去看的时候GC 又不频繁了。这种情况必须靠持续监控。jstat -gcutil pid 1000是一个非常好用的命令每秒打印一次各代的使用百分比和 GC 次数S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 82.05 96.87 93.41 90.30 12456 278.324 1879 1256.782 1535.106看到这个输出你会非常直观地感受到老年代已经占了 96%Full GC 发生了 1879 次Full GC 总耗时 1256 秒。这就解释了为什么业务总是时不时卡一下——Full GC 都在几百毫秒级别。如果环境不方便直接敲命令用 Arthas 的dashboard也能看到类似信息还能直接看到内存区和 GC 统计。另外我个人的经验是线上机器至少得有一套可视化监控哪怕是简单的 Prometheus Grafana把jvm_gc_collection_seconds、jvm_memory_bytes_used这类指标打出来比人到现场再抓要高效得多。3. 内存溢出的完整定位流程3.1 堆 OOM 的典型分析过程假设你拿到了堆 OOM 的 dump用 MAT 打开我最常看两个视图Dominator Tree和Leak Suspects。Leak Suspects是 MAT 自动分析的结论视图它会直接告诉你最大的几个对象以及持有它们引用链的起点。注意这个自动分析不一定总是准尤其当业务对象嵌套很深时MAT 常常把线程对象或者全局容器识别成“嫌疑人”但最终还是要回到业务代码去确认。Dominator Tree则是按对象保留尺寸从大到小排列的列表。我拿到一个 dump 之后习惯性先看前 20 个对象是什么。如果看到某个自定义业务对象占据了整个堆容量的 40% 以上那这个对象大概率就是问题核心。然后右键选择Path to GC Roots选择with all references看这个对象是怎么被引用的。如果它是被某个静态 Map 或者 List 持有那问题就非常明确了。这种场景太常见了——缓存没设上限、监听器没有解绑、ThreadLocal 没有清理最后堆被塞满。还有一种情况dump 里大量对象是同一个类型的数组比如byte[]或者Object[]。看到大量byte[]的时候优先怀疑图片传输、文件缓存、序列化缓存、批量导出接口。看到大量Object[]优先怀疑列表、队列容器。3.2 非堆 OOM元空间、直接内存、线程创建失败堆 OOM 是最常见的但不是全部。实际生产中还经常出现另外三类溢出如果不懂得区分半天都定位不到根因。元空间 OOM 的日志是java.lang.OutOfMemoryError: Metaspace。常见原因是动态生成类太多比如频繁使用 CGLib、ASM、反射生成代理类或者热部署场景下类加载器没有被卸载。定位思路是检查MaxMetaspaceSize是否有配置再用jstat -gcutil看 M 列元空间使用率是不是持续逼近 100%。真正的大坑在于类加载器泄漏会连带着使堆内存占用也不正常但根因在元空间。排查时可以加 JVM 参数-XX:TraceClassLoading -XX:TraceClassUnloading看看类加载情况确认是不是某个类在反复加载。直接内存 OOM 的典型日志是java.lang.OutOfMemoryError: Direct buffer memory。这类问题大部分和 Netty、RocketMQ 这类使用堆外内存的框架有关。定位思路是看 JVM 参数里的MaxDirectMemorySize再用jcmd pid VM.native_memory抓一下 NMTNative Memory Tracking快照。NMT 需要先用-XX:NativeMemoryTrackingsummary开启才能看到数据所以如果生产环境有这个风险建议提前开。线程创建失败的日志是java.lang.OutOfMemoryError: unable to create new native thread。这往往不是内存问题而是进程的线程数已经触达操作系统的限制或者地址空间不足。优先用ulimit -u确认用户最大进程/线程数用ps -eLf | grep pid | wc -l统计线程数量。很多情况下是代码在疯狂创建线程比如一个服务每来一个请求就 new 一个线程并发一高直接打爆。3.3 一个高频样例集合类缓存无限增长我处理过一个模拟项目 X 的案例现象是服务运行 3 天后老年代持续上涨每周固定触发一次 Full GCFull GC 一次耗时 10 秒左右。dump 里看到大量ConcurrentHashMap$Node对象和一个自定义的缓存数据模型类。顺着 GC Roots 找下来发现是一个静态的ConcurrentHashMapString, ListDataModel在作为缓存使用用户可以按条件批量查询数据查询结果全量塞进这个 Map且完全没有清理机制。作为“缓存”它的 key 又都是“用户ID业务数据ID”每次查询都会生成新的 key旧的 key 永远删不掉——这个 Map 最终膨胀到几个 GB。这就是最典型的“定时任务或接口把数据塞进静态集合里没有淘汰机制”导致的内存泄漏。想要修复并不难引入 Caffeine、Guava 这类带容量上限和过期策略的本地缓存一行配置就能恢复健康CacheString, ListDataModel cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.MINUTES) .build();但如果一开始就分析错方向把大量精力放在堆参数调优上怎么调都调不出效果。内存泄漏类问题的特征是“时间越长越卡”和并发请求量不是强相关真正的业务流量峰值类问题则是“流量一来就卡流量过了就恢复”。区分这两点能帮你快速收缩排查范围。4. GC 高频的本质分配速率、存活对象与晋升速度4.1 从 GC 日志读出关键趋势GC 频率高本质上只有三种可能分配速率太高、存活对象太多、晋升速度失控。分配速率太高指的是单位时间内新创建的对象量特别大导致年轻代很快被填满Young GC 被频繁触发。这种场景下 GC 日志里的特征是每次 Young GC 之后年轻代用量不大但下一次 GC 间隔时间极短可能只有几百毫秒。对象创建量大一般跟业务代码有关比如循环里一直 new 对象、字符串拼接、频繁拆箱装箱。存活对象太多指的是老年代里有大量对象无法被回收每次 Full GC 能回收的空间很有限。日志里典型的特征就是Full GC 前老年代 80%Full GC 后老年代还是 75%。这种时候先别着急调参大概率存在泄漏或者缓存没有淘汰策略。晋升速度失控指的是对象从年轻代晋升到老年代的速率异常快。比如某个接口创建了一批大对象直接超过了晋升阈值或者 Survivor 区放不下对象直接跑到老年代去。这种情况通常跟MaxTenuringThreshold、SurvivorRatio参数以及大对象有关。jstat -gcutil的连续输出可以帮助判断趋势。同一台机器如果老年代占比从 40% 到 60%、到 80%、然后触发 Full GC 之后回到 30%这属于正常波动如果每次 Full GC 之后回到 78%、79%、80%说明回收效果极差必然有东西占着不放手。4.2 从现象倒推常见原因我总结过一张很实用的现象对照表不需要高深理论看现象基本就能猜个八九不离十现象最常见原因先说结论怎么修Young GC 每秒钟好几次堆用量不大代码里疯狂创建临时对象找热点方法做对象复用减少循环内 newFull GC 频繁且回收前后老年代变化很小内存泄漏 / 大对象常驻dump MAT 分析定位引用链修代码老年代涨得很快一次 Full GC 能回收很多存活对象正常但晋升过多调整存活区大小、晋升阈值看是否分配速率超预期GC 停顿时间特别长达到秒级堆太大或 GC 器配置不合适考虑 G1、ZGC低延迟场景或调整 Region 大小Mixed GC 频繁触发G1老年代占用高、Humongous 大对象多用jmap -histo:live查大对象类型优化分配这其中的关键很多人容易忽略的是“回收前后变化很小”这一条。如果老年代回收前后只降了 5%那调大堆内存只是把水位线抬高了而已过段时间一样会打满。盲目的-Xmx并不能解决根因。4.3 G1 之后的常见坑JDK 9 默认垃圾回收器已经变成 G1很多人没注意到这点仍然用以前 CMS 时代的思维去调参结果问题反而变多。G1 把堆划分成多个 Region年轻代和老年代不再是一块连续的内存区域。它有一个概念叫 Humongous 对象指的是大于等于 Region 一半大小的对象。这些大对象会被直接放入 Humongous 区域属于老年代区域的一部分。如果你的代码里有大量“大数组、大集合、大 byte[]”G1 堆里会看到大量 Humongous Region这些区域很难回收而且容易导致 GC 频繁。遇到 G1 频率高我会先执行jmap -histo:live pid | head -40看有没有[Bbyte数组或者[Ljava.lang.Object;这种大型数组排在前面。G1 的 Region 大小可以通过-XX:G1HeapRegionSize显式设置默认从 1MB 到 32MB如果频繁出现 Humongous也可以考虑按实际对象大小调大 Region让对象不再被判为 Humongous。但这里有一个权衡Region 调大混合回收的粒度就变粗停顿可能会上升。所以常规建议是先精简大对象的分配再来调 Region。还有一个 G1 特有的问题很多人会设置-XX:MaxGCPauseMillis希望停顿控制在 200ms 以内。G1 会努力去满足这个目标但如果老年代占比长期偏高G1 会不断调大 Young 区或者增加 Mixed GC 次数导致 CPU 额外开销上升同时 GC 频率依旧很高。我见过一个案例明明吞度量不大但 CPU 全部耗在 GC 线程上了。那次的根因是业务代码中有一个定时任务每 30 分钟加载一次几百 MB 的静态数据强制分配到老年代老年代永远清不干净。5. 调优实操参数选型与完整排障复盘5.1 先有目标再调参别直接抄配置我见过太多人上网搜一个“JVM 调优最佳参数”复制粘贴就上生产。这种操作非常吓人。JVM 参数没有绝对的标准答案它依赖你的业务负载、对象模型、部署环境、响应时间要求。调参之前必须先明确目标目标是以吞吐量为优先批处理任务还是低延迟优先线上接口服务可忍受的最大停顿时间是多少业务高峰期的对象分配速率量级是多少机器内存和 CPU 核数是多少有没有和其他进程共享几种常见参数对比参数作用调整建议-Xms/-Xmx堆初始大小 / 最大大小生产环境建议两者设置相同避免运行期扩缩容停顿-XX:NewRatio老年代 / 年轻代比例默认 2老年代为年轻代的 2 倍。频繁 Young GC 时可适当增大年轻代-XX:SurvivorRatioEden / Survivor 比例默认 8Eden 是单个 Survivor 的 8 倍。晋升太快时可调大 Survivor 或调小 Eden-XX:MaxTenuringThreshold对象生命周期阈值默认 15。适当调低可以让短期对象不要反复拷贝-XX:UseG1GC选择 G1JDK 9 默认如果在低延迟场景可考虑-XX:MaxGCPauseMillisG1 的停顿时间目标不要设得太激进否则可能以 CPU 换停顿我的一个长期操作习惯是先保持默认参数确认根因后再调整一个参数观察一个完整业务周期再改下一个。一次只动一个变量出问题才知道是哪个参数引起的。5.2 完整排障复盘一个频繁 Full GC 的定位案例这里用一个虚构的模拟场景来完整串一遍排障流程。某交易查询服务部署规格是 4C8GJVM 参数为-Xms4g -Xmx4g -XX:UseG1GC。运行一段时间后监控平台报警接口平均响应时间从 60ms 涨到 1200msFull GC 次数在高峰期达到每分钟 20 次。我的排障步骤是第一步登录机器看 GC 日志。日志里发现 Full GC 的停顿在 800ms 到 1500ms 之间且一次 Full GC 之后老年代占用从 68% 降到 64%回收效果很差。这意味着老年代里大量对象本来就是存活的回收不掉。第二步用jstat -gcutil pid 1000观察。老年代 O 列数值持续在 95% 附近横盘Young GC 次数还在涨但老年代占用下不去。第三步连续抓了两个 dump间隔 10 秒。用 MAT 打开后发现有一个名为TradeFeeCacheEntry的对象数量在两次 dump 间从 18 万增长到 22 万持有对象总大小超过 2GB。第四步查看 GC Roots 路径。发现这些对象全部被一个 static 的LinkedHashMap持有每个查询请求会按用户区域加载该区域所有的计费规则到缓存 Map 里因为区域数量有限这个 Map 理论上不超过几万个 entry但实际 entry 数量是理论值的 20 倍——进一步看 key很多 key 带有随机字符串显然是每次请求把带有随机参数的商品编码也当成了缓存 key。根因确认缓存 key 设计不合理导致缓存无限膨胀。修复方案重构缓存 key 生成函数只保留业务主键同时给缓存容器接入淘汰策略比如 Caffeine。修复之后不要急着调 JVM 参数。修完代码先把-Xmx4g还原到默认值开启-XX:PrintGCDetails观察一个完整的业务高峰。当时的实际情况是Full GC 直接消失Young GC 频率也下降了 60% 还多因为缓存逻辑修复后对象分配速率同步大幅下降。这个案例的核心结论是频繁 GC 往往是业务代码“写坏了”而不是 JVM 参数配置“配坏了”。5.3 日常实践中的 5 条避坑心得第一线上 JVM 一定要开 GC 日志并且要滚动归档。不要舍不得那点磁盘空间。GC 日志在关键时刻是定位的唯一依据。配合-XX:HeapDumpOnOutOfMemoryError一起使用OOM 现场永远不会丢掉。第二不要在生产环境直接用jmap -dump:all在高峰期抓全量 dump。文件动辄几个 GB抓取过程会触发 stop-the-world对在线服务产生额外影响。如果现场压力很大可以先做一次jmap -histo:live看对象分布再决定要不要抓完整 dump。第三-Xms和-Xmx设成相同值是有道理的。运行期扩缩容本身会引起停顿而且扩容时内存申请失败的风险更高。但是堆设大了不等于 GC 频率会降低它只会推迟问题爆发的时间点。第四G1 的-XX:MaxGCPauseMillis不要太贪心。我以前试过把目标停顿设成 100ms结果为了满足这个目标G1 频繁发起垃圾回收整体吞吐量反而明显下降。后来改成 200ms服务表现远好于 100ms 的配置。第五任何参数变更之后至少监控两个完整的业务高峰周期再下结论。很多调整短期看起来有效是因为正好避开了数据量最大的时期。尤其是缓存类改造和 GC 参数调整都要经过峰值验证才算数。6. 在最后分享一个让我印象深刻的经验有一次处理一个服务的问题现象是老年代不断上涨Full GC 每 10 分钟一次dump 分析出来之后根因是日志框架的异步队列没有设置容量上限业务高峰期日志写入速度跟不上消费速度日志事件全部堆积在内存队列里。这个问题不深入看代码根本想不到因为我当时拿着 MAT 分析看到大量AsyncAppender$LoggingEvent对象时还愣了半天后来才意识到是日志框架的缓冲队列导致的内存积压。所以我想说的是JVM 调优并不只是熟悉 JVM 参数和工具更考验的是你如何把“对象在堆里的行为”翻译回“业务代码的运行逻辑”。dump 里面每一个可疑对象背后都是一个具体业务动作。你能不能在对象分布和代码逻辑之间建立清晰的联系决定了你排查 JVM 问题的效率上限。先学会用工具看清现场再学会把现场翻译回业务之后所有调优动作就都有的放矢了。

JVM调优先诊断后调参：内存溢出与GC频繁定位实战

相关推荐

查表、测接口、看日志、上服务器，我把它们塞进了一个窗口

CubeStudio多机多集群部署与按项目组分算力实操指南

数据库系统工程师2010年真题错题本：关系代数除法与两段锁协议深度拆解

更多资讯

Python游戏助手脚本实战：图像识别与自动化操作

离线JSON/XML格式化工具：跨平台零依赖实现

C# WinForms气象绘图工具：74年环流指数趋势图实战

JavaWeb图书管理系统：Eclipse+Tomcat环境搭建与排错

VB 2012随书源码实战：从编译运行到二次开发全解析

Micro-LED量产线MES在巨量转移这一段，该管到多细

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？