Java OOM 问题全解析

Java OOM 问题全解析：从原因定位到彻底根治

作者：没有逆称
标签：Java JVM OOM 内存泄漏 性能调优
阅读时间：约 15 分钟

前言

java.lang.OutOfMemoryError ------ 相信每一个 Java 开发者都被它折磨过。生产环境凌晨三点的告警，频繁 Full GC 之后的服务宕机，排查了半天发现是几年前留下的"祖传代码"......

OOM 的可怕之处不在于错误本身，而在于它往往是长时间问题积累的集中爆发，排查链路长、现场难复现。

本文结合实际生产经验，系统梳理 6 种常见 OOM 类型 ，对每一种都给出：触发原因 → 排查手段 → 解决方案 → 避坑建议，力求一文搞定。

[OOM 全景速览](#OOM 全景速览)
[Java Heap Space --- 堆内存溢出](#Java Heap Space — 堆内存溢出)
[GC Overhead Limit Exceeded --- GC 开销超限](#GC Overhead Limit Exceeded — GC 开销超限)
[Metaspace --- 元空间溢出](#Metaspace — 元空间溢出)
[Unable to Create New Native Thread --- 无法创建线程](#Unable to Create New Native Thread — 无法创建线程)
[Direct Buffer Memory --- 直接内存溢出](#Direct Buffer Memory — 直接内存溢出)
[Stack Overflow --- 栈溢出](#Stack Overflow — 栈溢出)
生产级排查工具箱
总结与最佳实践

1. OOM 全景速览

Java 的内存结构决定了 OOM 有多个"爆炸点"，先来一张全景图：

JVM 内存模型全景图

GC 触发区域：Young GC（Eden满）→ Old GC（Old满）→ Full GC（整个堆+Metaspace）

OOM 类型	触发区域	常见程度
Java heap space	堆内存	⭐⭐⭐⭐⭐
GC overhead limit exceeded	堆内存	⭐⭐⭐⭐
Metaspace	元空间	⭐⭐⭐
Unable to create new native thread	线程	⭐⭐⭐
Direct buffer memory	堆外内存	⭐⭐
StackOverflowError	栈	⭐⭐

2. Java Heap Space --- 堆内存溢出

2.1 错误表现

复制代码

java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3210)
    at java.util.ArrayList.grow(ArrayList.java:265)
    ...

2.2 触发原因

① 内存泄漏（最常见）

对象持有引用，GC 无法回收，随时间积累直到堆撑爆。

典型场景：

静态集合无限增长（static List/Map 只增不减）
未关闭的资源（Connection、InputStream）
监听器注册后未注销（Event Listener）
线程局部变量 ThreadLocal 未 remove

java 复制代码

// 💣 危险代码：静态 Map 充当"黑洞"
public class CacheManager {
    private static final Map<String, Object> CACHE = new HashMap<>();
    
    public void add(String key, Object value) {
        CACHE.put(key, value); // 只进不出，迟早 OOM
    }
}

② 内存溢出（数据量真的太大）

一次性加载超大数据集到内存（如全表查询几千万条数据）
生成超大文件（Excel、PDF）全部在内存中处理

2.3 排查手段

Step 1：开启 OOM 时自动 Dump

bash 复制代码

# JVM 启动参数中加入
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/logs/heapdump.hprof

Step 2：分析 Heap Dump

推荐工具：JProfiler（IDEA 官方推荐，可视化极强）

打开 JProfiler，选择 "Open a Heap Dump" 导入 .hprof 文件
点击 "Biggest Objects" → 直接展示占用内存最多的对象
使用 "Dominator Tree" → 分析对象引用树，定位泄漏根因
"References" 视图 → 查看谁在引用大对象，追溯到具体代码行

Step 3：线上快速定位（不重启）

bash 复制代码

# 手动 dump（需要进程 PID）
jmap -dump:format=b,file=/tmp/heap.hprof <PID>

# 查看堆内存概要
jmap -heap <PID>

# 实时查看 GC 情况
jstat -gcutil <PID> 1000 10

2.4 解决方案

方案	适用场景
修复内存泄漏代码	根本解法，强烈推荐
合理设置堆大小 `-Xmx`	内存真不够用时临时扩容
分批处理大数据	避免全量加载
引入缓存淘汰策略	用 `WeakHashMap`、Guava Cache 替代普通 Map
流式处理（Stream/游标）	大文件、大查询场景

java 复制代码

// ✅ 正确姿势：使用 MyBatis 游标批量处理
@Options(resultSetType = ResultSetType.FORWARD_ONLY, fetchSize = 1000)
@Select("SELECT * FROM big_table")
Cursor<BigData> streamAll();

// 配合使用
try (Cursor<BigData> cursor = mapper.streamAll()) {
    for (BigData data : cursor) {
        process(data); // 逐条处理，不全量加载
    }
}

3. GC Overhead Limit Exceeded --- GC 开销超限

3.1 错误表现

复制代码

java.lang.OutOfMemoryError: GC overhead limit exceeded

3.2 触发原因

JVM 默认阈值：GC 耗时超过 98% 的时间，而回收的内存不到 2%，连续多次后触发此 OOM。

本质上是"堆内存已满，GC 拼命跑却白忙活"的信号，往往先于 heap space OOM 出现。

3.3 排查与解决

排查方式同 堆内存溢出，核心是找到内存泄漏点。

临时规避（不推荐长期使用）：

bash 复制代码

# 关闭此限制检测（治标不治本）
-XX:-UseGCOverheadLimit

根治方向：

调大堆内存 -Xmx
优化对象创建，减少短生命周期大对象
使用合适的 GC 算法（G1/ZGC）

4. Metaspace --- 元空间溢出

4.1 错误表现

复制代码

java.lang.OutOfMemoryError: Metaspace

Java 8 之前是 PermGen space（永久代），Java 8 之后改为 Metaspace（元空间，使用本地内存）。

4.2 触发原因

Metaspace 存储类的元数据（类名、方法、字段信息等）。以下情况会导致类爆炸：

动态代理/字节码增强框架：如 Spring AOP、CGLib、ASM 运行时生成大量代理类
Groovy 动态脚本：每次执行都生成新的 Class
热部署/反复 reload：旧类无法被 GC（ClassLoader 有强引用）
OSGi 插件化架构：Bundle 频繁加载卸载

java 复制代码

// 💣 危险：在循环中动态生成类
for (int i = 0; i < 100000; i++) {
    // 每次都生成新的代理类，ClassLoader 持有引用无法 GC
    Object proxy = Proxy.newProxyInstance(
        classLoader, interfaces, handler
    );
}

4.3 排查手段

bash 复制代码

# 查看 Metaspace 使用情况
jstat -gcmetacapacity <PID>

# 查看加载了多少类
jstat -class <PID>

# JVM 参数：开启详细 GC 日志
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/gc.log

用 JVisualVM 或 Arthas 查看类加载数量趋势，若持续增长不下降 → 类泄漏确认。

4.4 解决方案

bash 复制代码

# 设置 Metaspace 上限，防止无限增长吃掉系统内存
-XX:MaxMetaspaceSize=256m

# 设置初始大小，减少频繁扩容
-XX:MetaspaceSize=128m

代码层面：

复用 ClassLoader，避免频繁创建
脚本引擎（Groovy/MVEL）使用缓存，不每次新建
检查框架版本，部分老版本 CGLib 有类泄漏 Bug

5. Unable to Create New Native Thread --- 无法创建线程

5.1 错误表现

复制代码

java.lang.OutOfMemoryError: unable to create new native thread

5.2 触发原因

这个 OOM 不是 Java 堆内存不足，而是：

系统线程数达到上限（Linux 默认每进程约 1024 个线程）
线程泄漏：线程池配置不当，任务堆积导致线程数失控
每个线程占用栈内存（默认 512KB~1MB），线程过多耗尽系统内存

5.3 排查手段

bash 复制代码

# 查看当前进程线程数
ps -eLf | grep java | wc -l

# 查看系统允许的最大线程数
cat /proc/sys/kernel/threads-max

# 查看每个用户的线程限制
ulimit -u

# Arthas 查看线程堆栈（神器）
java -jar arthas-boot.jar
# 进入后执行：
thread -n 10  # 查看 CPU 占用最高的 10 个线程
thread -b     # 查找死锁

jstack 分析线程 Dump：

bash 复制代码

jstack <PID> > /tmp/thread.dump
# 然后统计各线程状态
grep "java.lang.Thread.State" /tmp/thread.dump | sort | uniq -c | sort -rn

5.4 解决方案

① 调大系统线程限制

bash 复制代码

# 临时修改（重启失效）
ulimit -u 65535

# 永久修改 /etc/security/limits.conf
* soft nproc 65535
* hard nproc 65535

② 规范线程池使用

java 复制代码

// ❌ 错误：每次请求都创建新线程
new Thread(() -> doTask()).start();

// ✅ 正确：统一线程池管理
@Bean
public ThreadPoolExecutor taskExecutor() {
    return new ThreadPoolExecutor(
        10,          // corePoolSize
        50,          // maximumPoolSize
        60L,         // keepAliveTime
        TimeUnit.SECONDS,
        new LinkedBlockingQueue<>(1000),  // 有界队列！
        new ThreadFactoryBuilder().setNameFormat("task-%d").build(),
        new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
    );
}

⚠️ 强调：禁止使用 Executors.newCachedThreadPool()，其最大线程数为 Integer.MAX_VALUE，高并发下必炸。

6. Direct Buffer Memory --- 直接内存溢出

6.1 错误表现

复制代码

java.lang.OutOfMemoryError: Direct buffer memory

6.2 触发原因

DirectByteBuffer 分配的是堆外内存（Off-Heap） ，不受 -Xmx 限制，由 -XX:MaxDirectMemorySize 控制。

常见场景：

Netty / NIO 框架大量使用直接内存
手动调用 ByteBuffer.allocateDirect() 未及时释放
直接内存回收依赖 GC，但 GC 不频繁时堆外内存不释放

java 复制代码

// 💣 危险：频繁申请直接内存不释放
for (int i = 0; i < 10000; i++) {
    ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB
    // 忘记 ((DirectBuffer) buffer).cleaner().clean()
}

6.3 排查与解决

bash 复制代码

# 查看直接内存使用（通过 JMX）
jcmd <PID> VM.native_memory summary

# 设置直接内存上限
-XX:MaxDirectMemorySize=512m

代码层面：

Netty 使用 PooledByteBufAllocator 复用 Buffer
手动申请的 DirectBuffer 使用完后调用 cleaner().clean() 或等待 GC
升级 Netty 版本，新版本内存管理更完善

7. Stack Overflow --- 栈溢出

7.1 错误表现

复制代码

java.lang.StackOverflowError
    at com.example.Fibonacci.fib(Fibonacci.java:5)
    at com.example.Fibonacci.fib(Fibonacci.java:5)
    ...（重复 N 次）

严格来说 StackOverflowError 是 Error 不是 OOM，但生产环境同样会引发服务不可用。

7.2 触发原因

无限递归：递归终止条件缺失或错误
递归深度过大：数据结构深度超过栈容量（默认约 512~1024 帧）
对象循环引用 + JSON 序列化（如 toString/equals 触发无限调用）

java 复制代码

// 💣 死递归
public int factorial(int n) {
    return n * factorial(n - 1); // 忘记 if(n == 0) return 1;
}

7.3 解决方案

java 复制代码

// ✅ 方案一：修复递归终止条件
public int factorial(int n) {
    if (n <= 0) return 1; // 终止条件
    return n * factorial(n - 1);
}

// ✅ 方案二：改为循环（深度无限制）
public int factorial(int n) {
    int result = 1;
    for (int i = 2; i <= n; i++) {
        result *= i;
    }
    return result;
}

// ✅ 方案三：尾递归优化（Java 不原生支持，可用 Trampoline 模式）

调大栈深度（谨慎）：

bash 复制代码

-Xss2m  # 每个线程栈大小，默认 512K，调大会减少最大线程数

8. 生产级排查工具箱

8.1 Arthas ------ 线上诊断神器

bash 复制代码

# 下载并启动
curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

# 常用命令
dashboard          # 实时查看 JVM 状态
heap               # 查看堆内存
thread -n 5        # CPU 最高的 5 个线程
jad com.example.Foo # 反编译线上类
watch com.example.Foo methodName '{params,returnObj}' # 监控方法入参出参
trace com.example.Foo methodName  # 追踪方法调用链路耗时

8.2 常用工具对比

工具	适用场景	优点
JProfiler	IDEA 集成 Heap Dump 分析	可视化极强，IDEA 官方推荐
Arthas	线上动态诊断	无需重启，功能强大
JVisualVM	本地可视化监控	JDK 自带，图形化
jstack	线程 Dump 分析	简单直接，排查死锁
jmap	堆内存快照	配合 JProfiler 使用
jstat	GC 实时监控	轻量，适合快速判断
Prometheus + Grafana	长期监控告警	生产环境标配

8.3 推荐 JVM 参数配置（生产模板）

bash 复制代码

# 堆内存
-Xms2g -Xmx2g

# GC 选择（推荐 G1）
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

# OOM 自动 Dump
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/logs/

# GC 日志
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/var/log/gc-%t.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=20m

# Metaspace
-XX:MetaspaceSize=128m
-XX:MaxMetaspaceSize=256m

# 直接内存
-XX:MaxDirectMemorySize=512m

9. 总结与最佳实践

OOM 处理决策树

复制代码

                    OOM Error Occurred
                          │
                          ▼
            ┌─────────────────────────────┐
            │   查看完整错误信息            │
            │   确认 OOM 类型              │
            └─────────────────────────────┘
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
   │ Heap /      │  │ Metaspace / │  │ Direct /    │
   │ GC Overhead │  │ Thread OOM  │  │ Stack OOM   │
   └─────────────┘  └─────────────┘  └─────────────┘
          │               │               │
          ▼               ▼               ▼
   JProfiler        jstat -class     jcmd VM.
   分析 Dump       查看类加载        native_mem
                                       ory
          │               │               │
          └───────┬───────┴───────┬───────┘
                  ▼               ▼
           ┌─────────────┐  ┌─────────────┐
           │  找到根因    │  │  临时止血    │
           │  修复代码    │  │  扩内存/重启 │
           └─────────────┘  └─────────────┘
                  │               │
                  └───────┬───────┘
                          ▼
                ┌─────────────────┐
                │  完善监控告警    │
                │  (内存>80%预警) │
                └─────────────────┘

分步处理：

OOM 发生 → 第一时间查看完整错误信息，确认 OOM 类型
根据类型选工具 ：
- heap space / GC overhead → JProfiler 分析 Heap Dump → 找泄漏点
- Metaspace → jstat -gcmetacapacity <PID> 查类加载数量
- unable to create native thread → ps -eLf | grep java | wc -l 查线程数
- direct buffer memory → jcmd <PID> VM.native_memory summary 查堆外内存
- StackOverflow → jstack <PID> + Arthas thread -n 10 定位递归
临时止血：扩内存参数 / 重启服务
根治方向：修复代码 + 完善监控告警（内存使用率 > 80% 触发预警）

10 条黄金实践

始终开启 -XX:+HeapDumpOnOutOfMemoryError，确保出事时有案可查
禁止使用 Executors.newCachedThreadPool()，必须使用有界线程池
静态集合慎用，必须有淘汰机制（TTL/LRU/弱引用）
ThreadLocal 必须 remove()，避免内存泄漏
大数据集分批处理，拒绝全量加载到内存
资源必须关闭，使用 try-with-resources 语法
定期查看 GC 日志，关注 Full GC 频率和耗时
接入监控告警，内存使用率 > 80% 时触发预警
压测先于上线，暴露内存问题在生产环境之前
代码 Review 关注内存，重点审查集合、缓存、线程相关代码

结语

OOM 问题往往没有银弹，最有效的解法永远是找到根本原因，而不是盲目扩内存。扩内存只是推迟了爆炸时间，代码不改，总有一天还会炸。

希望这篇文章能成为你排查 OOM 时的参考手册。如果文章对你有帮助，欢迎点赞收藏 🌟，有问题欢迎评论区交流！

参考资料

JVM 规范 - Oracle 官方文档

JProfiler 官方文档

Arthas 用户文档

《深入理解 Java 虚拟机》------ 周志明

Java OOM 问题全解析