面试专题

如果系统出现 OOM，应该如何处理？

从线上止损、现场保留、OOM 类型识别、Heap Dump 与 GC 日志分析，到堆、元空间、直接内存、线程和容器内存定位，系统讲解 Java OOM 的处理方法。

难度：深入更新：2026-07-27

如果系统出现 OOM，应该如何处理？

面试回答

系统发生 OOM 后，我会先止损并保留现场，而不是立即反复重启。首先确认影响范围，通过摘除故障实例、切换流量、限流或关闭非核心功能保护系统；同时保存 OOM 错误、应用日志、GC 日志、Heap Dump、容器事件和监控数据。证据保存完成后，再由进程托管系统重启或扩容恢复服务。

然后根据错误类型确定排查方向。Java heap space 和 GC overhead limit exceeded 重点分析堆；Metaspace 重点检查类数量和 ClassLoader；Direct buffer memory 重点检查直接内存和 Netty/NIO Buffer；unable to create native thread 重点检查线程数量、线程栈、系统限制和进程原生内存；容器出现 OOMKilled 时，还要检查进程 RSS、容器内存限制以及堆外内存，因为它不一定会留下 Java OOM。

堆内存问题通常使用 Heap Dump、对象直方图和 GC 日志分析。重点查看占用最大的对象、Retained Size、Dominator Tree 和到 GC Roots 的引用链，并结合老年代在 Full GC 后是否持续增长，区分内存泄漏、正常容量不足和单次超大对象分配。修复后需要用相同流量模型验证内存能否回落、GC 是否恢复正常，同时补齐自动 Dump、GC 日志、内存分区监控和容量告警。

一句话总结：

OOM 处理的主线是先止损、再留证、按内存区域分类定位，最后区分泄漏、容量不足和异常大对象，并通过同等流量验证修复。

错误信息	主要排查方向
`Java heap space`	堆容量不足、对象泄漏、瞬时大对象
`GC overhead limit exceeded`	堆长期接近耗尽，GC 频繁但回收效果很差
`Metaspace`	类元数据过多、ClassLoader 泄漏、动态生成类失控
`Compressed class space`	压缩类指针空间不足
`Direct buffer memory`	NIO、Netty 等直接内存申请过多或释放不及时
`unable to create native thread`	线程过多、线程栈占用过大、系统线程限制或原生内存不足
`Requested array size exceeds VM limit`	代码尝试创建超过 JVM 限制的超大数组
容器 `OOMKilled`、退出码 137	进程总内存超过容器限制，不一定出现 Java OOM

因此，第一步不是直接调大 -Xmx，而是先确认错误类型和耗尽的内存区域。

二、第一阶段：先止损

线上故障首先要控制影响范围：

从负载均衡中摘除异常实例，避免继续接收新流量；
有健康副本时切换流量或临时扩容；
对非核心接口限流、熔断或降级；
暂停可能持续放大内存的批处理、消费任务或大查询；
确认现场信息已经保存后，再重启异常实例。

是否立即重启取决于可用性和取证条件。如果服务已经不可用，并且有自动生成的 Heap Dump、GC 日志和监控数据，可以尽快重启恢复；如果没有任何证据且仍能安全操作，应先保留必要现场。

不要让已经发生严重 OOM 的进程长期勉强提供服务。此时进程可能持续 Full GC、请求超时，甚至无法创建用于自救的新线程。

三、第二阶段：保留现场

1. 记录基本信息

至少保存：

完整 OOM 错误和调用栈；
故障时间、实例、版本和流量变化；
JVM 启动参数；
GC 日志；
Heap Dump；
堆、元空间、直接内存、线程数和进程 RSS 监控；
容器事件、退出原因和内存限制；
故障前后的发布、配置和任务变更。

2. 提前配置自动 Heap Dump

生产环境应在启动时配置：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/dumps

Dump 目录必须有足够空间和写权限，并有清理策略。Heap Dump 可能包含用户数据、令牌或业务字段，下载和保存时要遵守数据安全要求。

对于由进程托管系统负责自动拉起的无状态服务，可以评估：

-XX:+ExitOnOutOfMemoryError

它让 JVM 在 OOM 后退出，由 Kubernetes、systemd 等外部系统重启。是否使用取决于服务容灾能力，不能替代现场保留和根因修复。

3. 常用诊断命令

jcmd <pid> VM.flags
jcmd <pid> GC.heap_info
jcmd <pid> GC.class_histogram
jcmd <pid> Thread.print
jcmd <pid> GC.heap_dump /data/dumps/app.hprof

原生内存跟踪需要在 JVM 启动时开启：

-XX:NativeMemoryTracking=summary

开启后可以查看：

jcmd <pid> VM.native_memory summary

在线执行对象直方图或 Heap Dump 可能引起停顿和大量磁盘 I/O。操作前要确认磁盘空间、实例影响和可用副本，优先使用 OOM 时自动生成的 Dump。

Reason: OOMKilled
Exit Code: 137

这时进程可能来不及抛出 Java OOM，也可能没有 Heap Dump。容器计算的是进程总内存，不只是 Java 堆：

进程总内存
≈ Java Heap
+ Metaspace
+ Direct Memory
+ 线程栈
+ Code Cache
+ JVM 原生结构
+ 共享库和其他映射

如果 -Xmx 几乎等于容器内存上限，即使堆没有耗尽，也可能因为堆外空间、线程栈或 JVM 自身开销触发 OOMKilled。

五、Java Heap Space 如何分析

堆 OOM 通常要回答三个问题：

谁占用了内存？
为什么没有被回收？
占用是持续增长，还是一次性突增？

1. 先看 GC 趋势

重点观察：

老年代使用量是否持续增长；
Full GC 是否越来越频繁；
Full GC 后内存能否明显下降；
对象分配速率是否突然升高；
晋升速率和大对象分配是否异常；
GC 停顿是否已经影响业务。

典型判断：

Full GC 后老年代基线持续上升
→ 更像对象泄漏或无上限缓存

Full GC 后能够回落，但高峰期仍然耗尽
→ 更像容量不足或瞬时流量过大

内存突然被单次请求快速打满
→ 检查超大数组、文件、结果集或批次

2. 分析 Heap Dump

常用工具包括 Eclipse MAT、JDK Mission Control 和 VisualVM。

重点关注：

Histogram：各类对象的实例数和浅堆大小；
Dominator Tree：哪些对象支配了大量内存；
Retained Size：删除某对象后理论上能够释放多少内存；
Path to GC Roots：对象为什么仍然可达；
Leak Suspects：工具给出的泄漏候选，需要结合业务验证。

Shallow Size 只表示对象自身大小；Retained Size 还包括只能通过该对象访问的其他对象。排查泄漏时，Retained Size 通常更有价值。

3. 常见堆泄漏来源

没有容量上限或过期机制的本地缓存；
静态集合持续保存业务对象；
ThreadLocal 使用后没有清理；
监听器、回调或订阅关系只注册不注销；
队列无界，生产速度长期高于消费速度；
一次性加载超大文件、结果集或消息批次；
ORM 上下文、会话对象长期持有实体；
重试任务、Future 或上下文对象长期积压。

六、GC Overhead Limit Exceeded 是什么

这个错误表示 JVM 花费大量时间执行 GC，但回收出的空间很少。它通常是堆即将耗尽的结果，而不是一种独立内存区域。

排查方法与堆 OOM 基本一致：

查看 Full GC 频率和回收前后占用；
分析 Heap Dump 中的主要存活对象；
检查是否存在内存泄漏或缓存、队列无上限；
检查堆容量是否与真实负载匹配。

只关闭 GC overhead 检查通常没有解决根因，只会让进程以另一种方式继续恶化。

七、Metaspace OOM 如何分析

Metaspace 保存类元数据。发生 OOM 时重点检查：

已加载类数量是否持续增长；
是否频繁动态生成代理类、脚本类或字节码增强类；
是否存在大量无法卸载的 ClassLoader；
热部署、插件化或脚本引擎是否反复创建类加载器；
-XX:MaxMetaspaceSize 是否设置得过小。

可以使用：

jcmd <pid> VM.classloader_stats
jcmd <pid> GC.class_histogram

典型泄漏链路是：

业务线程、ThreadLocal、静态对象或第三方库
→ 持有自定义 ClassLoader
→ ClassLoader 持有其加载的全部 Class
→ 类元数据无法卸载

简单调大 Metaspace 只能延迟故障。类数量持续增长时，应定位是哪个 ClassLoader 和动态类生成逻辑没有释放。

八、Direct Buffer Memory 如何分析

直接内存位于 Java 堆之外，常见使用者包括 NIO、Netty、压缩库和网络框架。

重点检查：

DirectByteBuffer 数量和容量；
-XX:MaxDirectMemorySize；
Netty 池化内存和引用计数是否正确释放；
是否缓存了大量直接缓冲区；
是否存在大文件或网络数据的堆外缓冲；
进程 RSS 是否增长，但 Java 堆保持稳定。

如果启用了 NMT，可以通过：

jcmd <pid> VM.native_memory summary

查看 JVM 能追踪到的原生内存分类。需要注意，NMT 不能解释所有第三方原生库分配，仍要结合框架指标、进程 RSS 和操作系统工具分析。

九、Unable to Create Native Thread 如何分析

创建线程不仅需要 Java 对象，还需要原生线程和线程栈。常见原因包括：

线程池配置失控或不断创建新线程；
使用 newCachedThreadPool() 等高上限线程池承接阻塞任务；
每个请求或任务都手动创建线程；
线程阻塞、死锁或下游超时，旧线程迟迟不能释放；
-Xss 设置过大；
容器原生内存不足；
操作系统或容器的 PID、用户线程数限制。

排查时可以结合：

jcmd <pid> Thread.print
ps -eLf

重点统计线程总数、线程名称分布和线程状态，确认是哪一个线程池或业务模块持续增长。解决方向通常是限制线程数量、使用有界队列、修复阻塞和超时、释放线程资源，而不是只调整系统线程上限。

十、Requested Array Size Exceeds VM Limit

该错误通常说明代码尝试创建一个超过 JVM 可表示或可管理范围的数组，例如：

根据错误长度计算数组容量；
整数溢出后得到异常容量；
一次性把超大文件读入 byte 数组；
一次性拼接超大字符串；
查询结果或批处理缺少分页。

这类问题的重点是定位申请数组的调用栈并修改数据处理方式，例如分页、流式读取、分块处理或限制单次请求大小。单纯增加堆通常无效。

十一、如何区分泄漏、容量不足和异常大对象

现象	更可能的原因
Full GC 后老年代基线仍持续上升	对象泄漏、无上限缓存或队列
内存随流量上升，流量下降后能够回落	正常业务占用或容量不足
某次请求后内存瞬间大幅增长	超大对象、文件、结果集或批次
Java 堆稳定，但进程 RSS 持续增长	直接内存、线程栈或原生库
类数量和 Metaspace 持续增长	ClassLoader 或动态类泄漏
线程数持续增长并最终创建失败	线程泄漏、阻塞或线程池失控