OOM 引起原因以及如何排查？

面试考察点

考察面试者对 JVM 运行时数据区域的理解深度。面试官不仅想知道你知道有哪些区域，更想知道每个区域在什么情况下会抛出 OOM。
考察实际的问题排查与调优能力。这部分是重中之重，面试官想了解你是否真的处理过线上内存问题，是否熟悉常用的排查工具（如 jmap、jmat、JVisualVM、Arthas 等）以及分析堆转储文件的思路。
考察是否具备代码级别的敏感度。比如是否能从代码层面指出可能导致内存泄漏的典型模式（如未关闭的连接、不合理的缓存、ThreadLocal 误用等）。
考察对 JVM 参数配置的掌握。是否知道通过哪些参数可以控制各个区域的大小，以及如何设置这些参数来预防或定位 OOM。

核心答案

OOM（OutOfMemoryError） 是当 JVM 因为没有足够的内存来为对象分配空间，并且垃圾回收器也无法回收更多内存时，抛出的错误。它通常意味着应用程序存在内存泄漏，或者当前的内存设置不足以满足应用正常运行的需求。排查 OOM 的核心思路是：先确认是哪个区域内存溢出，再通过工具分析内存快照，定位到具体的对象和代码位置。

深度解析

OOM 的常见原因（分区域）

Java 不同内存区域的 OOM 原因各不相同，这也是面试中高频考察的细节。

Java 堆溢出（java.lang.OutOfMemoryError: Java heap space）
- 原因：这是最常见的 OOM。要么是对象太多（比如大流量下的缓存、批量处理数据），要么是存在内存泄漏，对象无法被垃圾回收（GC），导致堆内存被耗尽。
- 典型场景：高并发下的业务处理、一次性加载大量数据到内存（如从数据库查询未分页）、全局集合类不断添加对象而未移除、使用第三方库不当导致对象引用未被释放。
元空间/方法区溢出（java.lang.OutOfMemoryError: Metaspace / PermGen space）
- 原因：JDK 8 以后元空间替代了永久代。主要存放类的元数据、常量池等。如果应用动态生成了大量的类（如使用 CGLib 频繁生成代理类）、JSP 热部署过多，或者引入了大量的 jar 包，就可能耗尽元空间内存。
- 典型场景：Spring/MyBatis 等框架使用动态代理不当、JSP 应用频繁重新部署、某些 ORM 框架内部类缓存问题。
栈溢出（java.lang.StackOverflowError）与线程栈内存不足（OutOfMemoryError: unable to create new native thread）
- 原因：栈溢出通常是方法调用层次过深（最常见的是递归没有退出条件）。而无法创建新线程的 OOM，是因为创建的线程数量超过了操作系统的限制，或者进程的虚拟内存地址空间被占满（每个线程都要分配栈内存）。
- 典型场景：无限递归调用；服务器尝试创建数千甚至上万个线程（如高并发下不合理地使用线程池或不加控制的 new Thread()）。
直接内存溢出（java.lang.OutOfMemoryError: Direct buffer memory）
- 原因：使用 NIO 的 ByteBuffer.allocateDirect() 分配直接内存时，如果未及时释放，或者分配量超过了 -XX:MaxDirectMemorySize 的限制，就会抛出此错误。
- 典型场景：Netty 等 NIO 框架使用不当，导致大量直接内存未被回收。

如何排查 OOM？

这是一个系统性工程，我把它总结为“三板斧”思路：

第一步：开启堆转储（Heap Dump）。在 JVM 启动参数中加入：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump。这样当 OOM 发生时，JVM 会自动生成一份内存快照（.hprof 文件），这是排查的黄金数据。
第二步：使用工具分析 Dump 文件。拿到 hprof 文件后，可以用 Eclipse MAT (Memory Analyzer Tool) 或 JVisualVM 打开。
- 查看疑似泄漏对象：MAT 的 "Leak Suspects Report" 能直接给出可能的泄漏点。
- 分析 Dominator Tree：查看哪个对象占用内存最大，从 GC Roots 到该对象的引用链是什么。
- 检查集合类：特别关注 HashMap、ArrayList 等，看看里面是不是堆积了大量本该释放的对象。
第三步：结合日志与代码定位。如果 Dump 文件太大打不开，或者你想在 OOM 发生前监控，可以用 jstat 实时查看 GC 情况和堆占用趋势：
```
jstat -gcutil <pid> 1000 10  # 每秒打印一次 GC 情况，共 10 次
```
观察 Old 区占用是否持续增长且无法回收。同时，配合 jmap -histo 查看存活对象的直方图，看看哪些类的实例数量异常多。
第四步：如果是线程相关 OOM。无法创建线程时，检查操作系统层面：
```
ulimit -u          # 查看用户最大进程/线程数
cat /proc/sys/kernel/threads-max  # 系统级线程限制
```
同时用 jstack 打印线程栈，看是否有大量线程处于同一个状态（比如 BLOCKED）。

代码示例（模拟堆内存泄漏）

// 模拟一个简单的内存泄漏：往一个静态集合里不断放对象
import java.util.ArrayList;
import java.util.List;

public class OOMDemo {
    // 静态集合，生命周期和 JVM 一致，容易导致泄漏
    private static List<byte[]> LEAKY_LIST = new ArrayList<>();

    public static void main(String[] args) throws InterruptedException {
        while (true) {
            // 每次分配 1MB 数组，并添加到集合，导致无法被回收
            byte[] chunk = new byte[1024 * 1024]; // 1MB
            LEAKY_LIST.add(chunk);
            Thread.sleep(50); // 慢一点，便于观察
        }
    }
}
// 运行参数：-Xmx100m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./oom.hprof

运行后很快就会抛出 java.lang.OutOfMemoryError: Java heap space，并生成 oom.hprof 文件。用 MAT 打开后，你会看到 LEAKY_LIST 占据了绝大部分内存，并且有一个非常清晰的引用链：main thread -> OOMDemo.LEAKY_LIST -> byte[] 数组。

对比分析：不同区域 OOM 的表现差异

区域	错误信息	典型特征	主要排查方向
堆	Java heap space	GC 日志中 Full GC 频繁但回收效果差	分析堆转储，找大对象和泄漏点
元空间	Metaspace	加载了大量类，特别是动态生成的类	查看 `-XX:MaxMetaspaceSize`，检查字节码生成逻辑
栈/线程	unable to create new native thread	进程线程数已达上限	检查操作系统限制，减少线程数
直接内存	Direct buffer memory	使用 NIO 或 Netty 时出现	检查直接内存使用和释放

最佳实践（如何预防 OOM）

合理设置 JVM 参数：根据应用特点设置 -Xmx、-XX:MaxMetaspaceSize，给系统留出足够余量。
代码审查：注意集合类的使用，及时移除无用对象；确保流、连接等资源在使用后关闭（最好用 try-with-resources）。
使用软引用/弱引用：对于缓存场景，考虑使用 WeakHashMap 或 ReferenceQueue，让 GC 能回收不再使用的缓存对象。
压测与监控：上线前进行压力测试，观察内存曲线。线上使用监控工具（如 Prometheus + Grafana）实时监控 JVM 内存和 GC 情况。

常见误区

误区一：认为 OOM 一定是堆内存问题。忽略元空间、直接内存和线程栈的可能性。
误区二：发生 OOM 后立即重启应用。这会导致丢失现场，无法找到根本原因。正确的做法是先保留堆转储或相关日志，再重启。
误区三：盲目调大堆内存。如果不解决泄漏问题，调大内存只是延缓 OOM 发生，甚至可能导致 GC 时间更长，系统响应更慢。

总结

OOM 的本质是内存资源耗尽，排查的关键是区分内存区域、借助堆转储工具、分析对象引用链。只要掌握了各个区域的溢出特征和对应的分析工具，就能从容应对大部分 OOM 问题。

发布于2026年03月01日|13:01:11