JVM故障排查实战：内存溢出分析与死锁检测全流程指南

线上JVM告警响起来的那一刻多半是深夜。登录、看监控、抓线程栈、拉GC日志、下一份堆转储……这一套动作能不能在十分钟内做完决定了你是把故障控制在五分钟内还是熬到天亮。内存溢出和死锁检测就是JVM故障排查里最经典的两个科目也是我觉得最值得先吃透的部分。这篇文章就用我实际处理过的几种场景把从现象到根因的完整排查链条拆开讲工具、参数、判断依据都有适合后端开发、架构和运维同学放在手边当参考。排查之前先记住一句话不要一上来就重启也不要一上来就抓Dump先让机器多“活”一会儿证据往往比猜测值钱。1. 内存溢出的本质与常见类型1.1 先搞明白JVM内存模型仓库、工作台和排队区要查内存溢出首先得知道JVM把内存分成了几块每一块是干什么的。我用最通俗的方式描述一下堆内存像一个大型仓库所有对象都在里面分门别类存放虚拟机栈是每个线程的工作台方法调用的时候参数、局部变量都摆在台面上元空间更像一块登记板类信息、方法描述、常量池都记在那儿还有一块堆外内存不走堆由NIO、Netty这类框架直接分配归操作系统管。仓库内部又分新生代和老年代。新生代里又拆成Eden区和两个Survivor区S0、S1新对象先进Eden经过几次Minor GC还没死就挪进Survivor再熬过几次就晋升到老年代。老年代存大对象和长期存活对象Full GC主要扫这里。很多人以为OOM就是“仓库满了”实际不全是这样Metaspace满、虚拟栈深、堆外内存撑爆报错文案都含OutOfMemoryError但“爆点”完全不同排查方向天差地别。JVM和JRE/JDK的分工也可以顺带说清楚JVM是程序运行的虚拟机JRE是JVM加基础类库的运行环境JDK是开发工具包里面带着编译器、调试器和JVM本身。平时排查用的jmap、jstack、jstat都是JDK自带的诊断工具所以服务器上如果只装了精简版JRE很多工具是用不了的这也是“no suitable jvm was found to start the application”这类启动报错的高发原因之一——装了JRE但没装完整JDK或者32位/64位错配。1.2 OOM报错怎么看不同错误码对应不同“爆点”内存溢出的报错文案很多每一种背后都有一类典型场景。我按日常出现频率排个序你在日志里看到哪个就对号入座java.lang.OutOfMemoryError: Java heap space——堆内存耗尽。最常见的原因是大对象批量创建、集合没有清理、缓存无上限增长、查询一次拉回海量数据。如果是Tomcat这类容器里频繁出现还可能是线程内ThreadLocal持有大对象没释放。java.lang.OutOfMemoryError: GC overhead limit exceeded——GC快撑不住了。JVM在回收效率极低时主动抛出典型表现是回收后老年代仍然打不下来JVM发现GC占用CPU超过98%但回收量不足2%于是停机保护。这个报错本质上是“堆太满且回收不动”的预警。java.lang.OutOfMemoryError: Metaspace——元空间耗尽。动态代理、反射生成大量类、热部署反复加载ClassLoader都会把元空间塞满。Spring CGLIB代理、MyBatis映射、Groovy脚本动态编译都容易踩这条线。java.lang.OutOfMemoryError: unable to create new native thread——不能再创建原生线程了。一般不是内存不够而是线程数量打到操作系统限制或者堆内存和元空间过大导致留给线程栈的地址空间紧张。java.lang.OutOfMemoryError: Direct buffer memory——堆外直接内存耗尽。NIO、Netty分配ByteBuffer不经过堆使用了-XX:MaxDirectMemorySize限制或者代码没有及时回收DirectBuffer。java.lang.StackOverflowError——栈溢出。递归没有终止条件、调用层次过深比如深度递归遍历树结构或者正则表达式匹配的递归调用。排查的时候第一步永远是先看懂日志里的异常类全名。看到是Java heap space就别去查元空间阈值看到是GC overhead limit exceeded就先确认老年代的趋势方向错了再努力也白费。1.3 堆外内存和元空间那些容易忽略的OOM现场多数人查OOM习惯盯着堆但堆外内存和元空间这两块漏掉会特别亏。举一个我遇到过的例子一个文件上传服务用Netty接收大文件缓冲区在堆外分配堆内存一直很健康结果某个版本把缓冲区大小调大了两倍直接爆Direct buffer memory。这个时候你抓堆Dump根本看不到问题因为一切都在堆外正确做法是把启动参数里的-XX:MaxDirectMemorySize降下来同时用pmap或Native Memory TrackingJVM启动加-XX:NativeMemoryTrackingsummary然后用jcmd VM.native_memory看堆外内存的占用分布。元空间的问题通常和类加载挂钩。以前排查过一个用Groovy脚本做规则引擎的中间件每次规则变更都会重新编译脚本并加载新ClassLoader旧ClassLoader没人引用却因为元空间数据一直没被回收最后Metaspace撑爆。这种问题的核心不是“元空间太小”而是“类加载器泄漏”单纯把-XX:MaxMetaspaceSize调大只是拖延时间消灭无谓的类加载才是根本。还有一个容易被误导的场景是Java版游戏卡顿。老玩家都知道《我的世界》Java版性能受限很大程度上是GC停顿导致的——垃圾回收器在清理堆时应用线程全部暂停。这种“卡顿”不是死锁也不是OOM而是GC停顿时间过长排查时要去看GC日志的Pause Duration而不是抓线程栈。凡是遇到周期性、可预测的卡顿先怀疑GC再怀疑锁顺序别反。2. 内存溢出排查思路先看日志再抓堆转储2.1 生产上最优先的三件事jstat采样、GC日志、jmap诊断OOM一旦发生我建议按“无害 → 轻量 → 重量”的顺序取样。先说无害的GC日志。生产环境一定要把GC日志打开JDK 8及之前用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/logs/gc.logJDK 9以后用-Xlog:gc*:/logs/gc.log:time,uptime,level。GC日志记录了每次Minor GC、Full GC的耗时、堆各区域前后变化是判断内存泄漏趋势的第一手证据。没开GC日志的线上JVM遇到OOM等于睁眼瞎很多参数调优根本无从谈起。第二步是轻量的实时采样用jstat -gcutil pid 1000每秒钟输出一次各区域利用率。这条命令会自动连接本地JVM开销很小在故障现场可以放心跑。看输出时重点观察Eden区是不是频繁被打满、S0/S1是不是长期闲置、老年代利用率是不是一路上涨不回落。如果老年代涨上去就再也不下来哪怕还没有报OOM也已经可以写“内存泄漏嫌疑”的结论了。第三步是jmap的诊断命令比如jmap -heap pid可以直接看到堆配置和当前分区使用情况jmap -histo pid | head -20可以看到占用对象数量最多的前20个类。注意JDK 8的jmap -heap是正常的但JDK 11以上的版本会提示使用jcmd pid GC.heap_info功能类似。jmap -histo在生产上也可能造成短暂停顿执行前最好评估一下流量或者在低峰期操作。2.2 堆转储怎么抓、怎么分析MAT读盘全流程如果GC日志和jstat都指向堆内存异常下一步要抓堆转储。两种标准姿势一种是遇到OOM自动落盘启动参数加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/logs/dump/JVM在抛出OOM的瞬间把堆快照写下来这是最推荐的——故障现场的堆状态就是最真实的状态另一种是人工主动抓取jmap -dump:live,formatb,file/logs/dump/heap.hprof pid。注意live参数会让JVM先做一次Full GC把所有不可达对象清理掉再做快照这对生产服务是有影响的Full GC期间应用要停顿谨慎使用。抓到.hprof文件之后用Eclipse MAT或VisualVM打开。我习惯用MAT它的Leak Suspects报告会把“最可能造成泄漏的对象”自动列出来并画出GC Roots引用链。读报告时不要只盯着最大对象要看引用链——对象为什么没被回收是谁的强引用一直牵着它。常见结论无非几类一个全局Map不断PUT新对象一个缓存框架设置了过期时间但没有触发清理一个ThreadLocal存了HttpSession再也没remove。看Histogram和Dominator Tree可以快速定位持有大对象的入口。分析Dump很吃机器内存一个4G的堆文件本地至少得有8G以上的内存来跑MAT否则分析工具自己先OOM。我踩过这个坑后来定了个规矩线上堆文件不过8G就在笔记本分析超过8G直接用服务器分析别硬拖回本地。2.3 实战案例一次XSSFWorkbook大Excel导出引发的堆爆炸有个很典型的场景我处理过不止一次就是Excel导出导致OOM正好对应热搜里的“xssfworkbook内存溢出”。业务方要求导出十万行、几十列的数据第一版用POI的XSSFWorkbook直接在工作内存里构建整个Excel文档。XSSFWorkbook会为每一行、每一个单元格创建对象几十万对象压在堆里导出接口一调用老年代直接被打满紧接着就是Java heap space。当时的排查过程是这样的先看GC日志发现Full GC非常频繁老年代增长曲线接近45度再用jmap -histo看了一眼排在前面的全是org.apache.poi.xssf.model.SharedStringsTable、XSSFRow、XSSFCell这些POI对象这基本就实锤了再去抓Dump确认Dump里最大对象确实是POI的Workbook对象。解决思路不是单纯加堆而是换一个数据模型。POI本身提供了流式写入的SXSSFWorkbook它维护一个滑动窗口只有窗口内的行对象留在内存超过窗口的行会被刷到临时磁盘文件里。把代码从XSSFWorkbook切到SXSSFWorkbook并设置窗口大小比如100行堆内存占用瞬间降了几个量级。这里还要注意一个细节SXSSFWorkbook使用完毕必须调用dispose()方法释放临时文件否则磁盘上会堆积大量临时文件把磁盘打满。这种问题的教训很明确OOM的根因经常不在JVM参数而在“对象模型”。一次查询返回全部数据、一个大对象结构整体构建在内存里、一次IO读取直接加载整个文件这些都是典型的“内存不友好”写法靠加内存能撑一时撑不住增长。3. 死锁检测线程卡住不等于死锁3.1 死锁的四个条件与线程状态判断死锁是另一个让线上服务“假死”的经典问题。先说原理再谈检测。死锁要想发生必须同时满足四个条件互斥、持有并等待、不可抢占、循环等待。打个比方两个人各拿一把钥匙A等B手里的钥匙B等A手里的钥匙谁也不让谁也进不去门。Java的synchronized和ReentrantLock天然满足互斥和不可抢占所以代码里只要出现两个线程以不同顺序获取两把以上锁就存在死锁的理论风险。但线上“卡住”的原因太多了不能一看到线程状态不是RUNNING就怀疑死锁。线程状态为BLOCKED可能是普通锁竞争另一个线程马上释放锁它就能恢复为WAITING可能是park()或者Object.wait()等待别人唤醒还有大量线程卡在数据库查询、远程调用、网络IO上的情况线程状态是RUNNABLE但业务就是一直没结果。所以死锁检测的第一步不是找状态而是找“锁关系”谁持有锁、谁在等锁、等待的锁是不是形成了环。区分死锁和普通阻塞有个经验普通锁竞争很快会恢复线程切换频繁但系统吞吐还在死锁是两个及以上线程永久互相等待这组线程会一直不动CPU可能很低但被它们持有的资源全部瘫痪。看到一组线程长时间处于BLOCKED而且等待的锁ID相互指向基本就可以判定是死锁。3.2 jstack定位死锁5分钟的完整操作死锁检测最常用的工具是jstack。操作流程很固定用jps -l找到目标Java进程的PID。执行jstack pid /logs/thread.dump把线程快照落到文件。如果用的是ReentrantLock建议用jstack -l pid-l会额外打印锁的所有权信息对定位显式锁死锁很关键。打开文件搜索关键词deadlock、waiting to lock、locked、BLOCKED。jstack输出里如果检测到Java级死锁会在文件末尾直接给出一段“Found one Java-level deadlock”的总结把参与死锁的线程、锁地址、等待关系列得清清楚楚。这时候不要慌沿着它指出的线程名和锁地址回代码里找加锁顺序就行。还要提一个替代方案jcmd pid Thread.print作用和jstack基本一致在较新的JDK里更推荐。抓线程快照本身很轻量对生产影响极小所以遇到疑似死锁可以放心抓。我的习惯是每隔3秒抓一次连抓5次因为死锁线程的锁关系在不同时刻可能呈现不同侧面多抓几张交叉比对定位准确率高很多。3.3 转账业务死锁案例拆解从现象到根因用一个最经典的代码案例演示一下。两张账户互相转账线程A给账户1转给账户2线程B给账户2转给账户1如果加锁顺序恰好相反就会死锁。代码长这样public class TransferService { private final Object lockA new Object(); private final Object lockB new Object(); public void transferFromAtoB() { synchronized (lockA) { // 模拟业务耗时 synchronized (lockB) { // 执行账户扣减和增加 } } } public void transferFromBtoA() { synchronized (lockB) { // 模拟业务耗时 synchronized (lockA) { // 执行账户扣减和增加 } } } }两个线程同时跑A线程持有lockA等着lockBB线程持有lockB等着lockA服务里这两张账户的转账就永久卡住。此时jstack输出会这样提示Found one Java-level deadlock: Thread-0: waiting to lock 0x00000000d5ab7b58 (a TransferService$lockB) locked 0x00000000d5ab7b20 (a TransferService$lockA) Thread-1: waiting to lock 0x00000000d5ab7b20 (a TransferService$lockA) locked 0x00000000d5ab7b58 (a TransferService$lockB)看到这个输出根因已经不用猜了两个方法的加锁顺序不一致。修复方案有两个方向。第一个是固定加锁顺序给每个账户设一个全局唯一ID在任何代码里都先锁ID小的再锁ID大的从源头打破“循环等待”。第二个是用ReentrantLock.tryLock(long, TimeUnit)替代同步代码块带超时获取锁拿不到就放弃已持有的锁并记录告警让系统有机会自愈而不是干等。实践中我两种都试过对于转账这种强一致场景固定顺序更简单可靠对于链路复杂、锁多的场景tryLock超时机制更抗风险。3.4 不变式与防御写代码时怎么避免死锁排查死锁是亡羊补牢写代码时就应该防患于未然。我这里整理几条实战中验证过的方法统一加锁顺序。同一业务链路上的多把锁必须全局约定同一个获取顺序这是最简单也最有效的规则。缩小锁范围。锁的粒度越粗持有时间越长死锁概率越大。尽量只锁必要的修改操作不要在锁内做IO、远程调用、复杂计算。用显式锁替代synchronized。ReentrantLock支持tryLock超时能有效避免永久等待配合lockInterruptibly()还能响应中断比synchronized更可控。静态扫描工具辅助排查。IDEA自带Thread Analyzer、SonarQube里的死锁规则、SpotBugs的MC_OVERRIDABLE_METHOD_CALL_IN_CONSTRUCTOR等检查项可以在代码阶段发现不少隐患。数据库层的死锁也要防。两条SQL以不同顺序更新相同行集数据库也会死锁表现为Deadlock found when trying to get lock。这种问题靠应用层加锁顺序约束或者对数据库死锁做重试机制。防御做得好的项目死锁检测的告警基本常年为零。但防御做得好不代表可以不开检测监控依然得在。4. 常见问题排查速查表与实践避坑4.1 一张表带走常见症状、初始判断与应对把上面所有内容压缩成一张速查表贴到团队Wiki里当故障手册用非常合适症状/报错初始判断第一步动作常用命令/工具常见解法Java heap space堆内存不足或泄漏看GC日志和jstat老年代趋势jstat -gcutil、MAT分析Dump优化对象结构排查泄漏评估堆大小GC overhead limit exceeded回收效率极低确认Full GC频率和老年代占用GC日志、jmap -histo恢复堆空间分析大对象持有者Metaspace元空间满/类加载泄漏查看加载类数量增长趋势jcmd pid GC.class_stats修复类加载器泄漏必要时调大MaxMetaspaceSizeunable to create new native thread线程数打满或内存受限数线程数看进程线程上限top -H、jstack统计线程数排查线程创建循环调整线程池和ulimitDirect buffer memory堆外内存耗尽用NMT查看堆外分配jcmd pid VM.native_memory检查NIO缓冲区回收调整MaxDirectMemorySizeStackOverflowError递归无终止/调用过深看异常堆栈重复的调用链异常日志增加递归终止条件改成循环或尾递归线程长时间BLOCKED且互相等锁Java级死锁抓jstack查锁关系jstack -l、jcmd Thread.print统一锁顺序加锁超时重启后修复代码这张表不是我拍脑袋列的每一条都对应一次实际处理过的故障。把它打印出来贴在工位上遇到问题先对号可以少走很多弯路。4.2 我踩过的几个坑希望大家别踩排查JVM问题有一些非常容易犯的低级错误我挨个说一遍。第一一上来就重启。系统卡死运维习惯性先重启恢复结果现场全没了之后只能凭猜。正确顺序是先抓线程栈、再复制GC日志、再考虑抓Dump最后才重启。除非服务已经不可恢复否则证据优先。第二把jmap -dump:live当免费午餐。live会触发Full GC对高流量服务是实打实的停顿要评估能不能承受。如果只是想看对象统计先用jmap -histo别直接上Dump。第三抓了Dump不会分析。很多团队把Dump文件下载下来就完事了没人会MAT文件躺在磁盘里发霉。我建议团队里至少两个人熟练使用MAT和VisualVM并且提前配好和分析Dump环境相同版本的JDK不然打开Dump工具报版本不对直接卡在第一关。第四忽视JDK版本差异。JDK 9以后模块化带来了很多命令变化jmap -heap、GC日志参数、PermGen→Metaspace这些都是版本差异的重灾区。网上教程五花八门照着旧版本执行报错了还以为环境坏了用之前先确认java -version。第五混淆“假死锁”。服务卡死时先去查数据库连接池、外部依赖、线程池拒绝策略可能根本不存在Java级死锁而是拿不到数据库连接导致了线程互相等待。抓线程栈看栈顶方法如果都停在DriverManager.getConnection或者httpclient.execute这种地方那不是死锁是资源耗尽。4.3 巡检建议把排查能力沉淀成日常基线很多团队等到线上炸了才开始学排查这是最被动的状态。我建议平时就把几件事固化到流程里真出事的时候能力是现成的。所有Java服务上线前必须开启GC日志、HeapDumpOnOutOfMemoryError和HeapDumpPath。这是底线没有例外。建立资源基线。用jstat定期采样记录业务低峰期和高分期堆各区域的正常区间值。有了基线下次看到老年代涨了3倍立刻知道异常没有基线看到什么都判断不了。线程池线程名必须可读。创建线程池时用ThreadFactory设置有意义的名字比如order-async-thread这样jstack输出里一眼能认出是哪个业务线而不是pool-3-thread-1这种天书。定期做一次故障演练。在测试环境人为制造内存泄漏和死锁按标准流程从告警、抓证、定位到恢复跑一遍。演练过和没演练过真实故障时的应对差距是数量级的。把日常巡检做扎实线上出问题时就有底气。我个人实际操作中的体会是JVM故障排查七分靠规矩、三分靠命令。把GC日志、Dump自动落盘、线程名可读这几件事做好等于给排查白送了一半证据。最后再分享一个小技巧执行jstack时别只抓一次隔几秒连续抓四五次死锁的锁关系在不同时刻呈现的细节不同多张快照交叉比对定位速度和准确率都会明显提升。希望大家下次接到告警时手边已经有完整的现场资料而不是对着一个黑屏窗口干着急。