OOM 常⻅原因及解决⽅案

当 JVM 内存严重不⾜时，就会抛出 java.lang.OutOfMemoryError 错误，常⻅的 OOM 原因及其解决⽅法，如下图所示：

⼀. Java 堆空间(Java heap space)

案例1. java.lang.OutOfMemoryError:Javaheap space

当堆内存（Heap Space）没有⾜够空间存放新创建的对象时，就会抛出

java.lang.OutOfMemoryError:Javaheap space 错误（根据实际⽣产经验，可以对程序⽇志中的

OutOfMemoryError 配置关键字告警，⼀经发现，⽴即处理）。

造成原因

1. ⽆法在 Java 堆中分配对象，请求创建⼀个超⼤对象，如：⼤数组、⼤集合、⼤Map。
2. 内存泄漏（Memory Leak），⼤量对象引⽤没有释放，JVM ⽆法对其⾃动回收，常⻅于使⽤了
3. File 等资源没有回收，应⽤程序⽆意中保存了对象引⽤，对象⽆法被 GC 回收。
4. 吞吐量增加，超出预期的访问量/数据量，通常是上游系统请求流量飙升，常⻅于各类促销/秒杀活
5. 动，可以结合业务流量指标排查是否有尖状峰值。
6. 应⽤程序过度使⽤ finalizer。finalizer 对象不能被 GC ⽴刻回收。finalizer 由结束队列服务的守护
7. 线程调⽤，有时 finalizer 线程的处理能⼒⽆法跟上结束队列的增⻓

解决⽅案

单位对应：GB -> G, g；MB -> M, m；KB -> K, k

1. 使⽤ -Xmx 增加堆⼤⼩
2. 如果是超⼤对象，可以检查其合理性，⽐如是否⼀次性查询了数据库全部结果，⽽没有做结果数限
3. 制。
4. 如果是业务峰值压⼒，可以考虑添加机器资源，或者做限流降级。
5. 修复应⽤程序中的内存泄漏（需要找到持有的对象，修改代码设计，⽐如关闭没有释放的连接)

Jdk7之后常量池存放到堆，注意常量池过⼤引发堆OOM

案例2. GC overhead limit exceeded

当 Java 进程花费 98% 以上的时间执⾏ GC，但只恢复了不到 2% 的内存，且该动作连续重复了 5 次，

就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误。简单地说，就是应⽤程序

已经基本耗尽了所有可⽤内存， GC 也⽆法回收。

此类问题的原因与解决⽅案跟 Javaheap space ⾮常类似，可以参考上⽂。

⼆. ⽅法区(Perm gen 空间|Metaspace)

案例3. Permgen space

该错误表示永久代（Permanent Generation）已⽤满，通常是因为加载的 class 数⽬太多或体积太

⼤。

造成原因

PermGen 的使⽤量与加载到内存的 class 的数量/⼤⼩正相关，永久代存储对象主要包括以下⼏类：

1、加载/缓存到内存中的 class 定义，包括类的名称，字段，⽅法和字节码；

2、常量池；

3、对象数组/类型数组所关联的 class；

4、JIT 编译器优化后的 class 信息。

解决⽅案

根据 Permgen space 报错的时机，可以采⽤不同的解决⽅案，如下所示：

1、程序启动报错，修改 -XX:MaxPermSize 启动参数，调⼤永久代空间。

2、应⽤重新部署时报错，很可能是没有应⽤没有重启，导致加载了多份 class 信息，只需重启 JVM 即

可解决。

3、运⾏时报错，应⽤程序可能会动态创建⼤量 class，⽽这些 class 的⽣命周期很短暂，但是 JVM 默认

不会卸载 class，可以设置 -XX:+CMSClassUnloadingEnabled和 -XX:+UseConcMarkSweepGC这两个

参数允许 JVM 卸载 class。

如果上述⽅法⽆法解决，可以通过 jmap 命令 dump 内存对象 jmapdump:
format=b,file=dump.hprof ，然后利⽤ Eclipse MAT https://www.eclipse.org/mat 功能
逐⼀分析开销最⼤的 classloader 和重复 class。

案例4. Metaspace

JDK 1.8 使⽤ Metaspace 替换了永久代（Permanent Generation），该错误表示 Metaspace 已被⽤

满，通常是因为加载的 class 数⽬太多或体积太⼤。

此类问题的原因与解决⽅法跟 Permgenspace ⾮常类似，可以参考上⽂。需要特别注意的是调整

Metaspace 空间⼤⼩的启动参数为 -XX:MaxMetaspaceSize。

三. ⽅法栈(⽆法新建本机线程)

案例5. Unable to create native thread

内存不⾜，⽆法创建新线程。由于线程在本机内存中创建，报告这个错误表明本机内存空间不⾜。

每个 Java 线程都需要占⽤⼀定的内存空间，当 JVM 向底层操作系统请求创建⼀个新的 native 线
程时，如果没有⾜够的资源分配就会报此类错误。

造成原因

VM 向 OS 请求创建 native 线程失败，就会抛出 Unableto createnewnativethread，常⻅的原因包括

以下⼏类：

1、线程数超过操作系统最⼤线程数 ulimit 限制；

2、线程数超过 kernel.pid_max（只能重启）；

3、native 内存不⾜；

该问题发⽣的常⻅过程主要包括以下⼏步：
1、JVM 内部的应⽤程序请求创建⼀个新的 Java 线程；
2、JVM native ⽅法代理了该次请求，并向操作系统请求创建⼀个 native 线程；
3、操作系统尝试创建⼀个新的 native 线程，并为其分配内存；
4、如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒
绝本次 native 内存分配；
5、JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。

解决⽅案

1. 升级配置，为机器分配更多的内存

2. 减少 Java 堆空间⼤⼩，让出空间以便创建更多线程

3. 使⽤ -Xss 减⼩线程堆栈⼤⼩

4. 修复应⽤程序中的线程泄漏，严格避免在循环创建线程池，并保证线程池优雅关闭！。

5. 限制线程池⼤⼩；

6. 调⾼ OS 层⾯的线程最⼤数：执⾏ ulimia -a 查看最⼤线程数限制，使⽤ ulimit -u xxx 调整最⼤线

程数限制。增加操作系统级别的限制

四. 直接内存

案例6. Direct buffer memory

Java 允许应⽤程序通过 Direct ByteBuffer 直接访问堆外内存，许多⾼性能程序通过 Direct ByteBuffer

结合内存映射⽂件（Memory Mapped File）实现⾼速 IO。

原因分析

Direct ByteBuffer 的默认⼤⼩为 64 MB，⼀旦使⽤超出限制，就会抛出 Directbuffer memory 错误。

解决⽅案

1、Java 只能通过 ByteBuffer.allocateDirect ⽅法使⽤ Direct ByteBuffer，因此，可以通过 Arthas 等

在线诊断⼯具拦截该⽅法进⾏排查。

2、检查是否直接或间接使⽤了 NIO，如 netty，jetty 等。

3、通过启动参数 -XX:MaxDirectMemorySize 调整 Direct

ByteBuffer 的上限值。

4、检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项，如果有就去掉，因为该参数会使 System.gc()

失效。

5、检查堆外内存使⽤代码，确认是否存在内存泄漏；或者通过反射调⽤ sun.misc.Cleaner 的 clean()

⽅法来主动释放被 Direct ByteBuffer 持有的内存空间。

6、内存容量确实不⾜，升级配置。

五. 其它情况

案例7. Out of swap space

该错误表示所有可⽤的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical

Memory）和交换空间（Swap Space）两部分组成。当运⾏时程序请求的虚拟内存溢出时就会报 Outof

swap space? 错误。

原因分析

该错误出现的常⻅原因包括以下⼏类：

1、地址空间不⾜；

2、物理内存已耗光；

3、应⽤程序的本地内存泄漏（native leak），例如不断申请本地内存，却不释放。

4、执⾏ jmap-histo:live 命令，强制执⾏ Full GC；如果⼏次执⾏后内存明显下降，则基本确认为

Direct ByteBuffer 问题。

解决⽅案

根据错误原因可以采取如下解决⽅案：

1、升级地址空间为 64 bit；

2、使⽤ Arthas 检查是否为 Inflater/Deflater 解压缩问题，如果是，则显式调⽤ end ⽅法。

3、Direct ByteBuffer 问题可以通过启动参数 -XX:MaxDirectMemorySize 调低阈值。

4、升级服务器配置/隔离部署，避免争⽤。

案例8. Kill process or sacrifice child 杀死进程或⼦进程

有⼀种内核作业（Kernel Job）名为 Out of Memory Killer，它会在可⽤内存极低的情况下“杀死”

（kill）某些进程。OOM Killer 会对所有进程进⾏打分，然后将评分较低的进程“杀死”，具体的评分规则

可以参考 Surviving the Linux OOM Killer。

不同于其他的 OOM 错误， Killprocessorsacrifice child 错误不是由 JVM 层⾯触发的，⽽是由操作系统

层⾯触发的。

原因分析

OOM Killer机制，在可⽤内存极低的情况下会杀死进程

默认情况下，Linux 内核允许进程申请的内存总量⼤于系统可⽤内存，通过这种“错峰复⽤”的⽅式
可以更有效的利⽤系统资源。
然⽽，这种⽅式也会⽆可避免地带来⼀定的“超卖”⻛险。例如某些进程持续占⽤系统内存，然后导
致其他进程没有可⽤内存。此时，系统将⾃动激活 OOM Killer，寻找评分低的进程，并将其“杀
死”，释放内存资源。

解决⽅案

1、升级服务器配置/隔离部署，将进程迁移到不同的机器上,避免争⽤。

2、给机器增加更多内存

3、OOM Killer 调优。

与其他 OOM 错误不同，这是由操作系统⽽⾮ JVM 触发的。

案例9. Requested array size exceeds VM limit

JVM 限制了数组的最⼤⻓度，该错误表示程序请求创建的数组超过最⼤⻓度限制。

JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为

Integer.MAX_VALUE-2。

此类问题⽐较罕⻅，通常需要检查代码，确认业务是否需要创建如此⼤的数组，是否可以拆分为多个

块，分批执⾏。