★ FEATURED ARTICLE 写这篇文章之前我翻了翻自己过去几年的排障记录光是跟“java.lang.OutOfMemoryError”正面交锋的次数两只手都数不过来。从线上应用半夜突然假死到压测环境频繁触发Full GC导致接口超时再到容器内应用被莫名杀掉每一次OOM都不是重复的剧本但每一次排查的思路却有迹可循。这篇内容我不打算只做知识的搬运工更想把我实际踩过的坑、总结出的排查套路、以及最终沉淀下来的解决方案掰开揉碎讲清楚。如果你也正被Java内存问题折腾得焦头烂额或者想系统性地把OOM这个老大难问题一次吃透这篇文章应该能帮你省下不少弯路。1. OOM的本质不是内存不够这么简单很多人一看到OutOfMemoryError第一反应就是内存不够了加内存。这个直觉不能说错但离真相还很远。OOM在Java里是一个Error不是Exception这就意味着它通常不是你的代码try-catch能接住的而是JVM在内存资源无法继续分配时抛出的一种致命故障信号。1.1 JVM内存区域的划分决定了OOM的多样性要理解OOM必须先理解JVM运行时数据区是怎么分的。在Java 8及之后的版本里JVM的内存主要分为这么几块堆内存Heap存放对象实例这是OOM出现最频繁的地方。方法区/元空间Metaspace存放类元信息、常量池、方法描述等Java 8之后移到了本地内存。虚拟机栈VM Stack每个线程一个栈存放栈帧、局部变量表、操作数栈。本地方法栈Native Method Stack为native方法服务。本地内存Direct Memory / Off-Heap通过Unsafe或DirectByteBuffer分配的内存不经过堆。程序计数器PC Register记录当前线程执行的字节码行号。不同区域内存耗尽抛出的OOM异常信息是完全不一样的。这一点特别关键因为异常信息就是你排查的第一个路标。我遇到很多人一看到OOM就去看堆结果折腾半天发现是线程数爆了方向完全搞反。1.2 常见的OOM异常类型与信息特征我把实际生产环境中遇到过的OOM异常信息整理了一下你可以直接在日志里搜这些关键字来快速定位方向异常信息对应的内存区域常见根因Java heap space堆内存对象过多、内存泄漏、堆设置过小GC overhead limit exceeded堆内存GC回收效率极低98%时间在GC但回收不到2%内存Metaspace元空间动态生成类过多、类加载器未释放Direct buffer memory本地内存NIO/DirectByteBuffer使用不当堆外内存泄漏unable to create new native thread操作系统线程线程数达到系统上限或内存不足以创建新线程Out of memory: Kill process操作系统层面容器/物理机内存不足被系统OOM Killer杀掉通常JVM日志里没有堆栈这里要特别说一下GC overhead limit exceeded这个类型。它的含义是JVM检测到GC一直在跑但几乎回收不到内存已经在垃圾回收的泥潭里打转了。这种情况通常不是一瞬间产生的而是堆内存逐渐被占满Full GC越来越频繁最终JVM判定这不是正常状态直接抛出OOM。这种OOM往往比单纯的heap space更有预兆性如果你的监控系统做了GC频率和耗时告警是可以在OOM发生前提前感知并介入的。1.3 一个关键认知堆内存不等于全部内存这是新手最容易产生的认知偏差。JVM参数里的-Xmx设置的是堆的最大值但一个Java进程占用的总内存往往比-Xmx大不少。除了堆还有元空间、线程栈、JIT编译产物、GC回收器自身的管理结构、DirectBuffer、socket缓冲区等等这些都要占用操作系统内存。尤其是线程栈默认大小是1MB-Xss1m一个300线程的Java进程光线程栈就是300MB。如果容器内存限额只给了堆大小再加一点点余量线程数一涨就会把容器内存打满结果就是进程直接被操作系统Kill而不是JVM内的OOM。我自己就踩过这个坑。某次给容器设置-Xmx4g容器内存限额定的是5g看着是留了1g余量结果业务高峰期线程数冲到800多再加上堆外的一些缓存和Metaspace5g直接被顶穿容器健康检查失败实例被反复重启。这个问题的排查难度比单纯的Heap OOM高得多因为你看到的现象是实例重启不翻内核日志根本不知道是OOM Killer干的。2. 内存分配与回收机制搞清楚对象是怎么活到OOM的要把OOM从碰运气式排查变成有逻辑的破案你必须对JVM的内存分配路径和垃圾回收机制有一个扎实的理解框架。2.1 对象分配的第一站Eden区绝大多数对象刚创建时都出生在新生代Young Generation的Eden区。Eden区的大小可以通过-XX:NewRatio和-XX:SurvivorRatio来调整默认情况下新生代约占堆的1/3Eden与两个Survivor区的比例是8:1:1。这里有个很微妙的问题对象不一定永远留在新生代。当Eden区放不下新对象时会触发Minor GC存活的对象会移到Survivor区每经历一次Minor GC存活且年龄达到阈值默认15的对象会被晋升到老年代Old Generation。但如果Survivor区本身放不下存活对象就会触发分配担保机制直接把对象晋升到老年代。这个机制里隐藏着OOM的一个重要前兆如果老年代快速膨胀往往不是你主动去-set大对象而是有大量短命对象因为Survivor区空间不足被提前晋升了。我排查过一个典型的案例某个报表服务的Eden区设置的特别小因为-Xmx不大且NewRatio偏大结果大量查询中间对象直接涌进老年代老年代很快就满了Full GC频繁触发最终抛出heap space OOM。后来我把新生代比例调大Survivor空间也做了合理分配同样的业务流量下老年代增长曲线一下平缓了很多。2.2 大对象直接进入老年代Threshold参数-XX:PretenureSizeThreshold可以设置一个阈值超过这个大小的对象直接在老年代分配。这个设计的目的是避免大对象在新生代来回拷贝Eden到Survivor如果空间不够一个大对象会引发很多连锁反应。不过这里有个你需要知道的知识点PretenureSizeThreshold在Parallel Scavenger回收器下是直接生效的但在G1收集器中行为有所变化。G1的Humongous Object分配有自己的一套规则当对象大小超过Region大小的50%默认Region是1MB-32MB时会被视为巨型对象直接分配到连续的Humongous区域。实际项目中如果业务会创建大量的大数组或大集合你要特别关注这个参数的行为。我遇到过这样的情况一个接口从外部拉取数据每次构建一个几十MB的byte数组在Parallel GC下虽然会直接进老年代但至少分配过程是连续的切换到G1后大对象分配在Humongous Region里老年代回收时对Humongous区有特殊的回收策略处理不好反而会出现大对象导致的GC性能骤降。2.3 GC过程对内存释放的滞后性还有一个特别容易造成误判的点GC是尽力而为的不是内存不够就立刻回收。一个对象只要还被强引用持有GC就永远不会把它回收掉。这就是内存泄漏Memory Leak和内存溢出Memory Overflow的本质区别。内存泄漏是该释放的对象没释放对象无法被GC回收占用的内存越积越多内存溢出才是内存真不够用了可能瞬时请求量太大、分配需求超过堆上限。两者相互关联长期的内存泄漏最终必然导致内存溢出。所以你排查OOM时核心问题不是内存为什么不够而是哪些对象占着内存不放。这里我推荐你在脑海里建立一个简单的判定模型如果OOM发生是偶发的、瞬时流量高时触发多半是内存溢出调大堆或者优化对象分配能解决如果OOM是持续性的、隔几天准时出现、堆内存使用像楼梯一样逐级上升那基本就是内存泄漏必须找到泄漏的锚点。3. 典型OOM场景与根因分析哪些业务最容易踩雷每个OOM背后都有一段悲伤的故事。我根据自己的经验把最常见的OOM场景分成了几类每一类都有鲜明的特征你可以在实际排障时对号入座。3.1 堆内存泄漏最经典的OOM场景场景特征接口调用量不大但堆内存使用率呈稳定上升趋势每次GC后内存回收不彻底最终触发heap space。常见代码问题静态集合类持有对象不释放比如一个static HashMap不断往里put数据视图/上下文数据永远在里面躺着。连接资源未关闭数据库连接、HTTP连接、InputStream等没有在finally或try-with-resources中释放。监听器/回调未反注册事件监听器添加了但不移除被监听对象无法被回收。ThreadLocal使用不当线程池场景下ThreadLocal没有remove造成线程级的数据残留。这里我分享一个特别典型的排查过程。某微服务的堆内存线每天上涨十几个MB大约一周后准时OOM。dump堆内存后用MATMemory Analyzer Tool分析发现有一个ArrayList实例占用了超过30%的堆内存里面装的全是某种告警消息对象。顺着引用链追查发现代码里有个静态字段的List每次处理消息时往里add只有到达一定数量才会清空但业务改动后消息量猛增、清理逻辑被绕过去了。修复前先捞数据、清空、看堆内存曲线回落修复后这个内存爬坡就彻底消失了。3.2 大对象与集合爆炸突发性OOM场景特征某个特定接口或特定操作触发平时内存水位不高一旦有人调用某个功能内存瞬间飙升甚至直接OOM。常见场景一次性把全表数据导入内存做处理数百万行数据构建对象列表。大文件读取一次readAllBytes把几百MB文件纳入堆内存。批量查询没有分页一个SQL查了上千万条记录。JSP/模板渲染的巨型字符串拼接串行拼接大StringBuilder产生多个大对象。这类OOM的排查相对容易因为触发路径清晰。我印象很深的一个案例是某个导出功能前端点击导出后端要把一段时间内全部交易流水先查出来再写入文件。高峰期某次有客户选了全部历史时间段查询结果直接让堆内存原地起飞进程OOM。解决方案是改成流式查询分批写文件数据不落地堆内存路径完全重塑。3.3 线程数爆炸不占堆但占满进程内存场景特征JVM日志里没有明显的堆内存OOM堆栈但系统提示unable to create new native thread进程CPU可能打满系统负载居高不下。常见根因没有使用线程池每次请求new一个线程。线程池参数配置错误核心线程数设置过大队列容量无限任务积压后线程数持续膨胀。阻塞调用导致线程被占用比如不加超时的远程调用、等待锁超时无限等待。用户态内存耗尽每个线程默认栈大小1MB线程数一多进程的虚拟内存和真实内存占用都会暴涨。这里想强调一个极易忽视的点线程栈用的内存不归堆管所以即使你把-Xmx调低也没用相反如果-Xmx设置的过大留给线程栈的内存余量反而会变小出问题时能创建的线程数更少。有人为了防止堆OOM把堆调得很大结果线程数量骤减业务并发能力下降反而更容易触发线程类OOM。3.4 Metaspace膨胀类加载器泄漏的典型表现场景特征异常信息是Metaspace OOM堆内存正常但元空间持续增长。常见根因热部署场景中每次部署会创建新的类加载器旧的类加载器如果还引用着类或对象就会导致元空间无法回收。大量动态代理、CGLIB类生成、反射框架如各类增强框架在运行期疯狂生成类。每次SQL拼接产生不同的SQL字符串导致PreparedStatement缓存类膨胀。这类问题的排查要特别注意Metaspace回收的前提是类加载器可以被回收。如果你发现Metaspace稳定增长重点排查是不是有某个ClassLoader被长期持有。在部分框架中如果全局静态类引用了动态生成的代理对象那么该代理的类加载器永远无法释放Metaspace就只涨不跌。4. 排查方法论从现象到根因的完整实操手册这才是整篇文章含金量最高的部分。我会把我实际使用的排查步骤和工具使用方法一条一条列出来你可以直接照着操作。4.1 第一步保留案发现场OOM发生的第一要务不是立即重启服务而是把尸体留好。绝大多数JVM参数里都应该配置下面这两个参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/dump第一个参数的意思是当OOM发生且无法为主线程分配内存时自动导出堆dump文件。第二个是导出路径。加了这两个参数每次OOM时都会在指定目录留下一个.hprof文件这个文件就是破案的案发现场。如果你用的是容器注意HeapDumpPath要映射到持久化存储或者挂载卷里否则容器重启后dump文件随容器销毁丢失血泪教训。除了堆dump还应该开启GC日志。JDK 8及之前版本用-Xloggc:/data/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStampsJDK 9版本用-Xlog:gc*:/data/logs/gc.log:timeGC日志能帮你看到OOM前GC频率的变化趋势判断是慢性死亡还是突然暴毙。4.2 第二步确认OOM类型缩小排查范围先看异常堆栈的第一行找到java.lang.OutOfMemoryError后面跟着的关键字。我已经把常见的关键字和对应的排查方向整理成了一张速查表在实际排障中可以打印出来对照排查OOM类型优先排查方向参考工具Java heap space堆内对象占用、泄漏MAT、JProfile、heap dump分析GC overhead limit exceededGC频率、堆容量、对象存活GC日志、JStatMetaspace类加载器、动态代理JConsole的类加载数监控Direct buffer memory堆外内存缓冲、NIOJMX、pmap、Native Memory Trackingunable to create native thread线程数、OS线程上限jstack、系统ulimit、top -HKill process进程总内存超限容器监控、dmesg、内核日志这一步非常重要。很多同事跑来找我说JVM OOM了我第一句话就是问报的是什么类型的OOM如果是unable to create native thread你就算把堆dump文件翻烂也找不到答案。4.3 第三步分析堆dump文件定位内存大户拿到.hprof文件后我一般用MATEclipse Memory Analyzer做分析这个工具虽然界面复古但功能相当能打。分析步骤打开MAT选择File - Open Heap Dump加载大文件时建议给MAT自身分配足够内存MemoryAnalyzer.ini -Xmx4g打开后第一个要看的报表是Leak Suspects泄漏嫌疑点。MAT会自动列出最可疑的对象和引用链虽然经常有误报但能给你一个分析起点。我重点关注的是Histogram按对象占用大小排序。通常跑完能看到几个占用几十MB甚至GB的实例。选中某个大对象右键选择Path to GC Roots到GC根的引用路径选择with all references就能看到是谁拽住这个对象不让它被回收。这是一个非常实用的技巧一旦你找到GC Root - 业务对象的完整引用链代码里哪里持有引用就一清二楚了。举个小例子我曾经排查过一个OOMdump分析后发现最大的对象是一个HashMapPath to GC Roots显示的引用链是main thread - 某个Service实例 - static成员变量 - HashMap直接定位到代码里某个静态缓存没有清理机制修复代码后问题解决。4.4 第四步结合GC日志与监控看趋势堆dump是横截面GC日志是时间序列。两者结合才能把问题看得更立体。用GC日志查看工具如GCeasy、GCLogViewer分析gc.log重点看几个指标Full GC触发次数和频率如果Full GC几十秒一次说明老年代即将打满内存分配的速度远超回收速度。GC停顿时间如果GC耗时持续增长说明堆里的对象越来越多每次GC要遍历的对象数量变大。GC前后的堆占用对比每次GC之后堆内存是否有回落趋势。如果回收之后内存一直在上涨就是典型的泄漏信号。监控层面至少要有堆内存使用率、GC频率、GC耗时、活跃线程数四项指标的历史曲线。我个人比较习惯用的链路是先用Prometheus抓JVM指标jvm_memory_used_bytes、jvm_gc_pause_secondsGrafana上出看板再根据曲线特征判断是泄漏型还是突发型然后手动触发堆dumpjmap -dump:formatb,fileapp.hprof 落盘后用MAT深入分析。4.5 第五步线程问题的专项排查针对unable to create native thread或疑似线程膨胀的场景我的排查顺序是先看当前线程数jstack pid | grep java.lang.Thread.State | wc -l再看线程状态分布jstack pid | grep java.lang.Thread.State | sort | uniq -c | sort -rn如果在jstack输出里看到大量WAITING或BLOCKED状态的线程说明线程是在等待资源锁、队列时被积压了。再配合看系统层的限制ulimit -u cat /proc/sys/kernel/threads-max cat /proc/sys/vm/max_map_count最后看一眼进程实际占用的内存总量top -p pid系统层的-XX:MaxDirectMemorySize参数也能控制本地内存上限默认等同-Xmx。如果你用了DirectByteBuffer或netty这个参数要显式设置。4.6 完整排查流程示例我拿一个实际案例串一下完整排查过程大家能更直观地理解这五步怎么衔接。一个消息处理服务运行三天后OOM。报错信息是Java heap space。我按照流程保留现场后重启拿到dump和gc日志。先用GCeasy打开gc.log发现从第二天开始Full GC频率从每小时4次上升到每10分钟7次GC后堆余量从2G逐步涨到6G。这个趋势基本判断是泄漏型OOM。接着用MAT打开dumpHistogram显示byte数组和业务消息对象占比超过70%。通过Path to GC Roots追踪发现消息对象被一个延迟队列的实例引用而这个队列实例被一个单例的调度器持有。再看业务代码发现消息处理的失败分支里没有调用队列的remove操作导致堆积的消息对象只能进不能出。修复方案是在失败分支里清理引用同时给队列设置容量上限双保险。整个排查过程大约2小时比之前无头苍蝇式排查快了几倍。5. 解决方案与预防体系OOM的终结者要做的事排查出根因后怎么解决、怎么预防是决定这个坑会不会复发的最关键环节。我把解决方案分成三个层面代码层面、参数层面和架构层面。5.1 代码层面堵住泄漏源与降低内存压力代码层面的核心原则是不持有的对象早释放能分批处理的数据不一次性载入。具体手段包括资源统一通过try-with-resources释放避免连接、流、锁的泄漏。静态集合只保存索引/ID等轻型数据不要保存大对象整体。批量处理场景使用分批拉取batch size 1000-5000配合游标或翻页机制。定时任务处理大数据集时一次只保留批次内数据。ThreadLocal在使用完后执行remove操作尤其是线程池中复用的线程。对缓存严格设置过期时间和最大容量优先使用成熟缓存框架如本地缓存框架自带淘汰策略而非手写Map。特别强调的一点千万不能让修复泄漏变成单纯加内存。加内存只能延缓OOM爆发周期不能消除根因。而且在容器化环境中无脑调大堆容量是件非常危险的事一旦堆和其他内存叠加超过容器限额就会从JVM的OOM演变成进程被操作系统杀掉问题性质更严重。5.2 参数层面合理配置不是玄学JVM参数没有万能组合但有几条原则是经过实践验证的堆大小设置原则最好不要将-Xms和-Xmx设置成完全相同的固定值。很多人说设成一样能避免堆扩容带来的性能抖动这个说法有道理但我个人经验是在容器环境里建议-Xms和-Xmx保持一致避免运行中堆扩容导致的GC行为变化和内存波动。如果你对业务峰值内存估算有信心直接固定比较好。直接内存如果你的应用重度使用NIONetty、Elasticsearch客户端等显式设置-XX:MaxDirectMemorySize否则默认等同-Xmx很容易出现堆外内存占用失控。Metaspace-XX:MaxMetaspaceSize一定要设置。不设上限的话一旦出现类加载器泄漏元空间会无限增长直到把物理内存耗尽。建议的初始值可以给256m-512m观察然后根据监控数据调整。GC回收器选择JDK 8默认ParallelGCJDK 9默认G1。如果你的堆在4GB以下且追求最低延迟ParallelGC往往表现更好当堆超过4-6GB且业务需要可控的GC停顿时间G1是更合适的选择。JDK 11还可以用ZGC但在生产环境替换回收器前一定要做充分的压测。容器感知能力JDK 8u191及之后版本默认支持容器CPU/内存感知。如果你用的是旧版本必须显式设置-XX:UseCGroupMemoryLimitForHeap8u131或升级JDK。容器里Java进程的堆大小需要和容器限额保持合理余量一般建议堆大小为容器内存的50%-70%预留30%给线程栈、元空间、堆外内存。5.3 架构层面把OOM消灭在发生之前如果你的应用总是周期性地OOM即使每次都能定位和修复还是要反思架构层面的设计是不是存在系统性缺陷。以下几个方向值得关注数据分页与流式处理大数据量导出、导入、报表类接口架构上优先使用数据流式处理避免全量载入内存。削峰填谷瞬间高并发请求会导致短时间内创建大量对象即使单次请求内存不大总量也可能打爆堆。通过消息队列削峰、限流降级、异步化改造把瞬时峰值拉平。链路超时与容错给所有远程调用设置超时时间避免慢调用阻塞线程池防止线程堆积成新的OOM。压测常态化上线前的压测不只是看QPS要关注内存水位是否稳定、GC是否健康。正则通过流量压测找出内存增长的隐患点。告警体系完善对堆内存使用率、GC耗时、Full GC频率、线程数做分级告警。不是等到OOM报错才反应而是在内存水位异常的时候就能收到通知。5.4 一次完整的OOM治理复盘最后用一个综合案例做一次全景复盘。某业务团队反馈网关服务每周都会OOM两次已经持续一个月重启只能管两三天。我先看了一眼JVM参数发现堆内存设置-Xmx2g没有HeapDumpOnOutOfMemoryError也没有开GC日志等于裸奔。我给参数补齐了dump和日志配置并且结合容器内存调整了堆上限然后等待下次OOM发生。三天后dump文件如期产出。分析dump发现堆内存被大量WebSocket会话对象占用。通过引用链发现一个全局的SessionManager里保存了所有连接会话而某些客户端异常断开时服务端没有触发清理逻辑导致会话对象只增不减。修复清理逻辑后我又做了两个加固一是给SessionManager增加最大容量限制超过阈值时拒绝新连接并告警二是增加定时清理任务扫描心跳超时的会话并主动剔除。后续三周内再没有OOM告警。这次治理给我一个很深的感悟OOM从来不是内存不够这一个原因造成的而是由内存管理机制 业务代码 部署参数 监控告警四者综合决定的。任何一个环节缺失都可能让OOM成为悬而未决的顽疾。这行干久了你会发现OOM的排障能力本质上就是你对JVM理解的试金石。从最初的加内存吧到现在的先看dump再分析引用链这个成长过程没有捷径就是一次次和线上故障搏斗换来的。如果你看完这篇文章能建立起一套自己的OOM排查思路下次再遇到内存问题不至于一头雾水那这篇文章就算值了。还有个实用的小建议想留给你给自己的每个服务都加上-XX:HeapDumpOnOutOfMemoryError和GC日志参数哪怕你暂时觉得用不上。等到真出事的那一天你会谢自己当初多写的那两行参数。
阅读完成 · 觉得有帮助？
