OOM场景及解决方案

OOM类型

在《Java虚拟机规范》的规定里，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生 OutOfMemoryError 异常的可能。

本篇主要包括如下 OOM 的介绍和示例：

• java.lang.StackOverflowError
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Direct buffer memory
• java.lang.OutOfMemoryError: unable to create new native thread
• java.lang.OutOfMemoryError-->Metaspace
• java.lang.OutOfMemoryError：Metaspace
• java.lang.OutOfMemoryError: Requested array size exceeds VM limit
• java.lang.OutOfMemoryError: Out of swap space
• java.lang.OutOfMemoryError：Kill process or sacrifice child

StackOverflowError

JVM 虚拟机栈是有默认深度的，在执行方法的时候会伴随着入栈和出栈。栈上分配，标量分配等局部变量都消耗栈的大小

例子

/**
 * @Description: 栈溢出测试例子
 * @Author: jianweil
 * @date: 2021/9/14 19:30
 */
public class StackOverflowErrorDemo {
    
    public static void main(String[] args) {
        javaKeeper();
    }

    private static void javaKeeper() {
        javaKeeper();
    }

}

运行结果：

Exception in thread "main" java.lang.StackOverflowError
	at com.atguigu.java.oom.StackOverflowErrorDemo.javaKeeper(StackOverflowErrorDemo.java:15)

原因分析

• 无限递归循环调用（最常见原因）
• 执行了大量方法，导致线程栈空间耗尽
• 方法内声明了海量的局部变量
• native代码有栈上分配的逻辑，并且要求的内存还不小，比如 java.net.SocketInputStream.read() 会在栈上要求分配一个 64KB 的缓存（64位 Linux）

解决方案

• 修复引发无限递归调用的异常代码
• 排查是否存在类之间的循环依赖（当两个对象相互引用，在调用toString方法时也会产生这个异常）
• 通过JVM启动参数 -Xss 增加线程栈内存空间， 某些正常使用场景需要执行大量方法或包含大量局部变量，这时可以适当地提高线程栈空间限制
• 查看栈大小（0即是使用系统默认值）：
  • window: java -XX:+PrintFlagsFinal -version | findstr ThreadStackSize
  • linux: java -XX:+PrintFlagsFinal -version | grep ThreadStackSize
• 设置栈大小： -Xss128k（相当于-XX:ThreadStackSize=128k）

Java heap space

Java 堆用于存储对象实例，我们只要不断的创建对象，并且保证 GC Roots 到对象之间有可达路径来避免GC清除这些对象，那随着对象数量的增加，总容量触及堆的最大容量限制后就会产生内存溢出异常。

Java 堆内存的 OOM 异常是实际应用中最常见的内存溢出异常。

例子

/**
 * @Description: 堆溢出例子
                 JVM参数：-Xmx12m
 * @Author: jianweil
 * @date: 2021/9/14 19:57
 */
public class JavaHeapSpaceDemo {

    static final int SIZE = 2 * 1024 * 1024;

    public static void main(String[] a) {
        int[] i = new int[SIZE];
    }

}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.atguigu.java.oom.JavaHeapSpaceDemo.main(JavaHeapSpaceDemo.java:13)

原因分析

• 请求创建一个超大对象，通常是一个大数组
• 超出预期的访问量/数据量，通常是上游系统请求流量飙升，常见于各类促销/秒杀活动，可以结合业务流量指标排查是否有尖状峰值
• 过度使用终结器（Finalizer），该对象没有立即被 GC
• 内存泄漏（Memory Leak），大量对象引用没有释放，JVM 无法对其自动回收，常见于使用了 File 等资源没有回收

解决方案

• 针对大部分情况，通常只需要通过 -Xmx 参数调高 JVM 堆内存空间即可。
• 如果是超大对象，可以检查其合理性，比如是否一次性查询了数据库全部结果，而没有做结果数限制
• 如果是业务峰值压力，可以考虑添加机器资源，或者做限流降级。
• 如果是内存泄漏，需要找到持有的对象，修改代码设计，比如关闭没有释放的连接

内存溢出(out of memory)，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个 Integer，但给它存了 Long 才能存下的数，那就是内存溢出。

内存泄露( memory leak)，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存，迟早会被占光。memory leak 最终会导致 out of memory！

GC overhead limit exceeded

JVM 内置了垃圾回收机制GC，我们不需要手工编写代码来进行内存分配和释放，但是当 Java 进程花费 98% 以上的时间执行 GC，但只恢复了不到 2% 的内存，且该动作连续重复了 5 次，就会抛出 java.lang.OutOfMemoryError:GC overhead limit exceeded 错误（俗称：垃圾回收上头）。

简单地说，就是应用程序已经基本耗尽了所有可用内存， GC 也无法回收。

假如不抛出 GC overhead limit exceeded 错误，那 GC 清理的那么一丢丢内存很快就会被再次填满，迫使 GC 再次执行，这样恶性循环，CPU 使用率 100%，而 GC 没什么效果。

例子

/**
 * @Description: 复现java.lang.OutOfMemoryError: GC Overhead Limit Exceeded错误
 *
 *              -Xmx280m -XX:+UseParallelGC
 *
 * @Author: jianweil
 * @date: 2021/9/14 16:25
 */
public class OutOfMemoryGCLimitExceed {
    public static void addRandomDataToMap() {
        Map<Integer, String> dataMap = new HashMap<>();
        Random r = new Random();
        while (true) {
            dataMap.put(r.nextInt(), String.valueOf(r.nextInt()));
        }
    }

    public static void main(String[] args) {
        addRandomDataToMap();
    }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
	at java.lang.Integer.toString(Integer.java:403)

原因分析

由于GC回收不了资源，触发了该错误的条件报错了，这个程序的最终错误，和 JVM 配置也会有关系，如果设置的堆内存特别小，会直接报 Java heap space。在资源受限的情况下，无法准确预测程序会死于哪种具体的原因。通过微调-Xmx大小试多几次会出现java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

解决方案

• 添加 JVM 参数-XX:-UseGCOverheadLimit 不推荐这么干，没有真正解决问题，只是将异常推迟
• 检查项目中是否有大量的死循环或有使用大内存的代码，优化代码
• dump内存分析，检查是否存在内存泄露，如果没有，加大内存

Direct buffer memory

我们使用 NIO 的时候经常需要使用 ByteBuffer 来读取或写入数据，这是一种基于 Channel(通道) 和 Buffer(缓冲区)的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆里面的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样在一些场景就避免了 Java 堆和 Native 中来回复制数据，所以性能会有所提高。

Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存，许多高性能程序通过 Direct ByteBuffer 结合内存映射文件（Memory Mapped File）实现高速 IO。

例子

• ByteBuffer.allocate(capability) 是分配 JVM 堆内存，属于 GC 管辖范围，需要内存拷贝所以速度相对较慢；
• ByteBuffer.allocateDirect(capability) 是分配 OS 本地内存，不属于 GC 管辖范围，由于不需要内存拷贝所以速度相对较快；

/**
 * @Description: -Xms10m,-Xmx10m,-XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m
 * @Author: jianweil
 * @date: 2021/9/14 20:15
 */
public class DirectBufferMemoryDemo {
    public static void main(String[] args) {
        System.out.println("maxDirectMemory is:" + sun.misc.VM.maxDirectMemory() / 1024 / 1024 + "MB");
        //ByteBuffer buffer = ByteBuffer.allocate(6*1024*1024);
        ByteBuffer buffer = ByteBuffer.allocateDirect(6 * 1024 * 1024);
    }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
	at java.nio.Bits.reserveMemory(Bits.java:694)

原因分析

如果不断分配本地内存，堆内存很少使用，那么 JVM 就不需要执行 GC，DirectByteBuffer 对象就不会被回收，这时虽然堆内存充足，但本地内存可能已经不够用了，就会出现 OOM，本地直接内存溢出。

解决方案

• Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，因此，可以通过 Arthas 等在线诊断工具拦截该方法进行排查
• 检查是否直接或间接使用了 NIO，如 netty，jetty 等
• 通过启动参数 -XX:MaxDirectMemorySize 调整 Direct ByteBuffer 的上限值
• 检查 JVM 参数是否有 -XX:+DisableExplicitGC 选项，如果有就去掉，因为该参数会使 System.gc()失效
  • 直接内存与System.gc()关系
• 检查堆外内存使用代码，确认是否存在内存泄漏；或者通过反射调用 sun.misc.Cleaner的 clean() 方法来主动释放被 Direct ByteBuffer 持有的内存空间
• 内存容量确实不足，升级配置

unable to create new native thread

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

例子

/**
 * @Description: todo
 * @Author: jianweil
 * @date: 2021/9/14 20:33
 */
public class NativeThreadDemo {
    public static void main(String[] args) {
        while(true){
            new Thread(() -> {
                try {
                    Thread.sleep(Integer.MAX_VALUE);
                } catch(InterruptedException e) { }
            }).start();
        }
    }
}

运行结果：

Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread

原因分析

• 线程数超过操作系统最大线程数限制（和平台有关）
• 线程数超过 kernel.pid_max（只能重启）
• native内存不足；该问题发生的常见过程主要包括以下几步：
  • 1. JVM内部的应用程序请求创建一个新的 Java 线程；
  • 2. JVM native 方法代理了该次请求，并向操作系统请求创建一个 native 线程；
  • 3. 操作系统尝试创建一个新的 native 线程，并为其分配内存；
  • 4. 如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒绝本次 native 内存分配；
  • 5. JVM 将抛出 java.lang.OutOfMemoryError:Unableto createnewnativethread 错误。

解决方案

• 想办法降低程序中创建线程的数量，分析应用是否真的需要创建这么多线程
• 如果确实需要创建很多线程，调高 OS 层面的线程最大数：执行 ulimia-a 查看最大线程数限制，使用 ulimit-u xxx 调整最大线程数限制

Metaspace

JDK 1.8 之前会出现 Permgen space，该错误表示永久代（Permanent Generation）已用满，通常是因为加载的 class 数目太多或体积太大。随着 1.8 中永久代的取消，就不会出现这种异常了。

Metaspace 是方法区在 HotSpot 中的实现，它与永久代最大的区别在于，元空间并不在虚拟机内存中而是使用本地内存，但是本地内存也有打满的时候，所以也会有异常。

• java.lang.OutOfMemoryError-->Metaspace
• java.lang.OutOfMemoryError：Metaspace

例子

/**
 * @Description: -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
 * @Author: jianweil
 * @date: 2021/9/14 20:45
 */
public class MetaspaceOOMDemo {
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(MetaspaceOOMDemo.class);
            enhancer.setUseCache(false);
            enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> {
                //动态代理创建对象
                return methodProxy.invokeSuper(o, objects);
            });
            enhancer.create();
        }
    }
}

运行结果：

Exception in thread "main" org.springframework.cglib.core.CodeGenerationException: java.lang.OutOfMemoryError-->Metaspace

原因分析

方法区溢出也是一种常见的内存溢出异常，在经常运行时生成大量动态类的应用场景中，就应该特别关注这些类的回收情况。这类场景除了上边的 CGLib 字节码增强和动态语言外，常见的还有，大量 JSP 或动态产生 JSP 文件的应用（远古时代的传统软件行业可能会有）、基于 OSGi 的应用（即使同一个类文件，被不同的加载器加载也会视为不同的类）等。

解决方案

• 方法区在 JDK8 中一般不太容易产生，HotSpot 提供了一些参数来设置元空间，可以起到预防作用
  • -XX:MaxMetaspaceSize 设置元空间最大值，默认是 -1，表示不限制（还是要受本地内存大小限制的）
  • -XX:MetaspaceSize 指定元空间的初始空间大小，以字节为单位，达到该值就会触发 GC 进行类型卸载，同时收集器会对该值进行调整
  • -XX:MinMetaspaceFreeRatio 在 GC 之后控制最小的元空间剩余容量的百分比，可减少因元空间不足导致的垃圾收集频率，类似的还有 MaxMetaspaceFreeRatio

Requested array size exceeds VM limit

例子

/**
 * @Description: Requested array size exceeds VM limit
 * @Author: jianweil
 * @date: 2021/9/14 20:38
 */
public class ArraySizeExceedsVMLimitDemo {
    public static void main(String[] args) {
        int[] arr = new int[Integer.MAX_VALUE];
    }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit

原因分析

• JVM 限制了数组的最大长度，该错误表示程序请求创建的数组超过最大长度限制。
• JVM 在为数组分配内存前，会检查要分配的数据结构在系统中是否可寻址，通常为 Integer.MAX_VALUE-2。

解决方案

检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。

Out of swap space

启动 Java 应用程序会分配有限的内存。此限制是通过-Xmx和其他类似的启动参数指定的。

在 JVM 请求的总内存大于可用物理内存的情况下，操作系统开始将内容从内存换出到硬盘驱动器。

原因分析

该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（Virtual Memory）由物理内存（Physical Memory）和交换空间（Swap Space）两部分组成。

Kill process or sacrifice child

操作系统是建立在流程概念之上的。这些进程由几个内核作业负责，其中一个名为“ Out of memory Killer”，它会在可用内存极低的情况下“杀死”（kill）某些进程。OOM Killer 会对所有进程进行打分，然后将评分较低的进程“杀死”，具体的评分规则可以参考 Surviving the Linux OOM Killer。

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

原因分析

默认情况下，Linux 内核允许进程申请的内存总量大于系统可用内存，通过这种“错峰复用”的方式可以更有效的利用系统资源。

然而，这种方式也会无可避免地带来一定的“超卖”风险。例如某些进程持续占用系统内存，然后导致其他进程没有可用内存。此时，系统将自动激活 OOM Killer，寻找评分低的进程，并将其“杀死”，释放内存资源。

解决方案

• 升级服务器配置/隔离部署，避免争用
• OOM Killer 调优。

参考与感谢：java 9种常见的OOM场景——原因分析及解决方案

深入理解JVM系列

• 1.深入理解JVM（一）一一 简介和体系结构
• 2.深入理解JVM（二）一一 类加载器子系统
• 3.深入理解JVM（三）一一 运行时数据区（虚拟机栈）
• 4.深入理解JVM（四）一一 运行时数据区（程序计数器+本地方法栈）
• 5.深入理解JVM（五）一一 运行时数据区（堆）
• 6.深入理解JVM（六）一一 运行时数据区（方法区）
• 7.深入理解JVM（七）一一 执行引擎（解释器和JIT编译器）
• 8.深入理解JVM（八）一一 字符串常量池
• 9.深入理解JVM（九）一一 对象实例化和内存布局
• 10.深入理解JVM（十）一一 字节码层面剖析程序执行过程
• 11.深入理解JVM（十一）一一 垃圾回收相关概念
• 12.深入理解JVM（十二）一一 垃圾回收相关算法
• 13.深入理解JVM（十三）一一 详解垃圾回收器
• 14.深入理解JVM（十四）一一 对象分布图
• 15.深入理解JVM（十五）一一 class文件结构
• 16.深入理解JVM（十六）一一 字节码指令集
• 17.深入理解JVM（十七）一一 类的生命周期详解
• 18.深入理解JVM（十八）一一 再谈类的加载器
• 19.深入理解JVM（十九）一一 JVM监控及诊断工具(命令行）
• 20.深入理解JVM（二十）一一 JVM监控及诊断工具(GUI)
• 21.深入理解JVM（二十一）一一 JVM运行时参数(收藏篇)
• 22.深入理解JVM（二十二）一一 分析GC日志
• 23.深入理解JVM（二十三）一一 OOM场景及解决方案