JVM04-JVM中内存溢出以及其处理方法

前言

上一篇我们介绍了JVM03–JVM垃圾收集机制的一些基本概念，这一篇介绍一下JVM中各种内存溢出及其处理方法。
本文会按照JVM中内存划分来介绍各种内存溢出的例子。

一些基本的设置说明

为了模拟出内存溢出的效果，我们需要手动设置内存区域的内存大小，下面就是设置值部分设置值及其说明。

分类	选项	说明
虚拟机栈	-Xss	每个线程的栈大小
堆空间	-Xms	启动JVM时的初始堆大小
堆空间	-Xmx	堆空间最大值
堆空间	-Xmn	新生代大小(1.4or lator) 注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8
新生代空间	-XX:NewRatio	新生代与老年代的比例
新生代空间	-XX:NewSize	新生代大小
新生代空间	-XX:SurvivorRation	Eden区域SurvivorRation区的比例
永久代空间	-XX:PermSize	启动JVM时的初始永久代大小
永久代空间	-XX:MaxPermSize	永久代空间最大值
元空间	-XX:MetaspaceSize	指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集进行类型卸载，同时收集器会对该值进行调整；如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过 -XX:MaxMetaspaceSize 的情况下，适当提高该值。
元空间	-XX:MaxMetaspaceSize	设置元空间最大值，默认是-1，即不限制，或者说只受限于本地内存大小
元空间	-XX:MaxMetaspaceFreeRatio	在垃圾收集之后控制最小的元空间剩余容量的百分比，可减少因为元空间不足导致的垃圾收集的频率
直接内存	-XX:MaxDirectMemorySize	设置直接内存的最大大小，如果不设置的话则默认与Java堆最大值（由-Xmx指定）一致

堆内存溢出

Java堆用于存储对象的实例，我们只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出。Java堆内存的OutOfMemoryError异常是实际应用中最常见的内存溢出异常情况。出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟随进一步提示“Java heap space”。下面举个例子来模拟堆内存溢出。这里将-Xms和-Xmx都设置成20M，保证了Java堆内存不可扩展。然后，通过-XX:HeapDumpPath指定dump文件的保存位置。这里通过while循环不断的创建对象，然后保存到集合中。

/**
 * Java堆内存异常
 VM Args:
 //这两个参数保证了堆中的可分配内存固定为20M
 -Xms20m
 -Xmx20m

 -XX:+HeapDumpOnOutOfMemoryError //自动生成dump文件
 //文件生成的位置，作为生成在桌面的一个目录
 -XX:HeapDumpPath=D:\srv\dump
 *
 * @author xiang.wei
 * @date 2020/5/27 13:35
 */
public class HeapOOM {
    /**
     * 创建一个内部类用于创建对象使用
     */
    static class OOMObject {
    }

    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<>();
        //无限的创建对象放在堆中
        while (true) {
            list.add(new OOMObject());
        }
    }
}

下面简单的说一下在Idea中设置应用运行内存的方法，我们只需要在 Run---->Edit Configurations—>找到需要设置的主类，然后在VM options中添加

 -Xms20M -Xmx20M -Xmn20M   -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\srv\dump

如下图所示：

上面程序运行结果如下：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to D:\srv\dump\java_pid23624.hprof ...
Heap dump file created [28062091 bytes in 0.143 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.jay.service.HeapOOM.main(HeapOOM.java:31)
Java HotSpot(TM) 64-Bit Server VM warning: MaxNewSize (20480k) is equal to or greater than the entire heap (20480k).  A new max generation size of 19968k will be used.

我们可以看到程序生成了dump文件到指定目录，打开jvisualvm.exe工具导入heapDump文件，相应的说明如下图所示：

一共创建了802858个实例，消耗了 98.9%的运行内存。
切换到实例数如下图所示：

如何解决堆内存的OOM异常呢，首先需要确认内存中导致OOM的对象是否是必要的，也就是要先分清楚到底是出现了内存泄露（Memory Leak）还是内存溢出(Memory Overflow)。

Java栈内存异常

说完了Java堆内存异常，下面我们来看看Java栈内存异常，在实际开发中发生栈内存异常的情况比较少。Java栈内存异常发生的两种情况是：

1. 如果线程请求的栈深度（栈深度：指目前虚拟机栈中没有出栈的方法帧）大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。这种情况在递归的场景下可能会出现，如果在使用递归算法时没有控制好递归的跳出条件，就有可能会出现这种情况，下面的例子就是一个没有跳出条件的递归调用。根据前面说明，我们可以通过-Xss160k设置栈容量为160K。
2. 如果虚拟机的栈内存允许动态扩展，当扩展容量无法申请到足够的内存时，将抛出OutOfMemoryError异常。
   如下这个例子：

/**
 * VM Args:
 *    设置栈容量为160K，默认1M
 *    -Xss160k
 * @author xiang.wei
 * @date 2020/5/27 16:09
 */
public class JavaVMStackSOF {

    private int stackLength = 1;

    public void stackLeak() {
        stackLength++;
        System.out.println("*********栈的深度是:" + stackLength);
        //递归调用
        stackLeak();
    }

    public static void main(String[] args) throws Throwable {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try {
            oom.stackLeak();
        } catch (Exception e) {
            throw e;
        }
    }
}

运行结果如下：

*********栈的深度是:1287
Exception in thread "main" java.lang.StackOverflowError
	at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77)

可以看到，递归调用了1287次，栈容量不够用了。
默认的栈容量在正常的方法调用时，栈深度可以达到1000-2000深度，所以，一般的递归可以承受的住，如果代码中出现了StackOverflowError，首先需要检查代码，看看是不是递归写的不对。不能只是调参数。
当创建很多线程时，容易出现OOM（OutOfMemoryError），这时可以通过具体情况，减少最大堆容量，或者栈容量来解决问题。
线程数(最大栈容量)+最大堆值+其他内存（忽略不计或者一般不改动）=机器最大内存*
当线程数比较多时，且无法通过业务上减少线程数，再不换机器的情况下，我们只能把最大栈容量设置小一点，或者把最大堆值设置小一点。

方法区和运行时常量池溢出

由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放在一起进行。需要注意的是HotSpot从JDK7开始逐步“去永久代”的计划，并在JDK8中完全使用元空间代替永久代，使用"永久代"还是"元空间"来实现方法区，对程序的影响是不同的。
元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存，因此，默认情况下元空间的大小仅受本地内存限制，但仍可以通过参数控制：
-XX:MetaspaceSize与-XX:MaxMetaspaceSize来控制大小。
方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，要达成的条件是比较苛刻的。在经常运行时生成大量动态类的应用场景里，就应该特别关注这些类的回收状况，这类场景除了之前提到的程序使用了CGLib字节码增强和动态语言外，常见的还有：大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGI的应用（即使是同一个类文件，被不同的加载器加载也会被视为不同的类）。
方法区的主要职责是用于存放类型的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。 对于这部分区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出为止。
这是因为在调用CGLib创建代理时会生成动态代理类，即Class对象到Metaspace，所以while一下就出异常了。
下面这个例子就是通过设置元空间大小，然后，通过动态代理生成大量的类，来模拟元空间内存溢出的情况。

/**
 * 在JDK8下测试方法区，所以设置了Metaspace的大小为固定的8M
 -XX:MetaspaceSize=8m
 -XX:MaxMetaspaceSize=8m
 * @author xiang.wei
 * @date 2020/5/27 17:29
 */
public class JavaMethodAreaOOM {
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(JOOMObject.class);
            enhancer.setUseCache(false);
            enhancer.setCallback((MethodInterceptor) (obj, method, objects, methodProxy) -> methodProxy.invokeSuper(obj,objects));
            //无限创建动态代理，生成class对象
            enhancer.create();
        }
    }
    static class JOOMObject{}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
	at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:538)
	at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)

直接内存溢出

直接内存导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见有什么明显的异常情况，如果发现内存溢出之后产生的Dump文件很小，而程序中又直接或者间接使用了DirectMemory（典型的的间接使用就是NIO）,那就可以考虑重点检查一下直接内存方面的原因了。
直接内存溢出的举例;

Exception in thread "main" java.lang.OutOfMemoryError
    at sun.misc.Unsafe.allocateMemory(Native Method)

总结

本文首先介绍了堆内存溢出（OutOfMemoryError）发生的场景以及处理方式，OutOfMemoryError发生的场景主要就是系统创建了大量的对象，并且这些对象是有效的（即保证GC Roots到对象之间有可达路径）。然后，介绍了栈内存异常（StackOverflowError）的发生场景以及处理方式，StackOverflowError发生的场景主要是线程调用栈深度超过了虚拟机运行的栈深度。最后，介绍了方法区的内存溢出。需要注意的是JDK1.8中完全移除了永久代，取而代之的是元空间。