深入理解Java虚拟机(2)之四-OutOfMemoryError异常实战

Java虚拟机规范描述中，除了程序计数器虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能。

Java堆溢出

Java堆用于存储对象实例，只要不断创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制就会产生内存溢出异常。

/**
 * VM args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 * -Xms20m -Xmx20m  限制Java堆大小为20m
 * -XX:+HeapDumpOnOutOfMemoryError  让虚拟机在出现内存溢出异常时Dump出当前内存堆转储快照以便事后进行分析
 *
 * @author LeoQin
 * @date 2019-05-27 22:10
 */
public class HeapOOM {

    static class OOMObject {
    }

    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<>();
        while (true) {
            list.add(new OOMObject());
        }
    }
}

运行：

java -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError HeapOOM

结果：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid2557.hprof ...
Heap dump file created [27584567 bytes in 0.108 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3210)
        at java.util.Arrays.copyOf(Arrays.java:3181)
        at java.util.ArrayList.grow(ArrayList.java:265)
        at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
        at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
        at java.util.ArrayList.add(ArrayList.java:462)
        at oom.HeapOOM.main(HeapOOM.java:22)

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，就会出现以上信息。

要解决这个区域的异常，需要分清到底是出现内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

如果是内存泄漏，可通过工具检查泄漏对象到GC Roots的引用链。就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们。

如果不是泄漏，检查虚拟机的堆参数(-Xms和-Xmx)，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长，尝试减少程序运行期的内存消耗。

---

虚拟机栈和本地方法栈溢出

HotSpot虚拟机不区分虚拟机栈和本地方法栈，因此对于HotSpot来说，虽然-Xoss参数(设置本地方法栈大小)存在，但实际是无效的，栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，Java虚拟机规范中描述了两种异常：

• 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverError异常。

• 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

这两种异常存在相互重叠的地方：当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，其本质上只是对同一件事情的两种描述而已。

尝试以下两种方法均无法让虚拟机产生OOM异常，都是获得StackOverError异常。

• 使用-Xss参数减少栈内存容量。结果：抛出StackOverError异常，异常出现时输出的堆栈深度相应缩小。
• 定义大量本地变量，增大此方法帧中本地变量表的长度。结果：抛出StackOverError异常，异常出现时输出的堆栈深度相应缩小。

第一种方法的测试程序：

/**
 * VM args: -Xss160k
 *
 * @author LeoQin
 * @date 2019-05-27 22:44
 */
public class JavaVMStackSOF {
    private int stackLength = 1;

    public void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try {
            oom.stackLeak();
        } catch (Throwable e) {
            System.out.println("stack length:" + oom.stackLength);
            throw e;
        }

    }
}

运行：

java -Xss160k JavaVMStackSOF

结果：

stack length:772
Exception in thread "main" java.lang.StackOverflowError

---

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

String.intern()是一个Native方法，它的作用是：如果字符串常量池包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并返回此String对象的引用。

/**
 * VM args: -XX:PermSize=10M -XX:MaxPermSize=10M
 * 限制方法区大小
 *
 * @author LeoQin
 * @date 2019-05-27 22:56
 */
public class RuntimeConstantPoolOOM {

    public static void main(String[] args) {
//        使用list保持常量池引用，避免Full GC回收常量池行为
        List<String> list = new ArrayList<>();
        int i = 0;
        while (true) {
            list.add(String.valueOf(i++).intern());
        }
    }
}

运行：

java -XX:PermSize=10M -XX:MaxPermSize=10M RuntimeConstantPoolOOM.class

结果：

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=10M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=10M; support was removed in 8.0

类的元数据, 字符串池, 类的静态变量将会从永久代移除, 放入Java heap或者native memory. 其中建议JVM的实现中将类的元数据放入native memory, 将字符串池和类的静态变量放入java堆中. 这样可以加载多少类的元数据就不在由MaxPermSize控制, 而由系统的实际可用空间来控制。

本机直接内存溢出

DirectMemory 容量可通过 -XX：MaxDirectMemorySize 指定，如果不指定，则默认与 Java 堆最大值（ -Xmx 指定）一样，下面程序利用 DirectByteBuffe 模拟直接内存溢出的情况。

/**
 * VM Args: -XX:MaxDirectMemorySize=10M
 *
 * @author LeoQin
 * @date 2019-05-27 23:16
 */
public class DirectBufferOOM {

    public static void main(String[] args) {
        final int _1M = 1024 * 1024;
        List<ByteBuffer> buffers = new ArrayList<>();
        int count = 1;
        while (true) {
            ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1M);
            buffers.add(byteBuffer);
            System.out.println(count++);
        }
    }
}

运行：

java -XX:MaxDirectMemorySize=10M DirectBufferOOM

结果：

1
2
3
4
5
6
7
8
9
10
Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
        at java.nio.Bits.reserveMemory(Bits.java:694)
        at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
        at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
        at oom.DirectBufferOOM.main(DirectBufferOOM.java:20)

ByteBuffer并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常。下面的程序利用 Unsafe 类模拟直接内存溢出。

/**
 * VM Args: -XX:MaxDirectMemorySize=10M
 *
 * @author LeoQin
 * @date 2019-05-27 23:08
 */
public class DirectUnsafeOOM {
    public static final int _1MB = 1024 * 1024;

    public static void main(String[] args) throws Exception {
        Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);
        }
    }
}

运行：

java -XX:MaxDirectMemorySize=10M DirectUnsafeOOM

结果：

Exception in thread"main"java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory（Native Method）
at org.fenixsoft.oom.DMOOM.main（DMOOM.java：20）

由 DirectMemory 导致的内存溢出，一个明显的特征是在 Heap Dump 文件中不会看见明显的异常，如果读者发现 OOM 之后 Dump 文件很小，而程序中又直接或间接使用了 NIO ，那就可以考虑检查一下是不是这方面的原因。

---

该文章来源《深入理解Java虚拟机》

---

以上