《深入理解 Java 虚拟机》笔记——第2章 Java内存区域与内存溢出异常（二）

声明：

本博客是本人在学习《深入理解 Java 虚拟机》后整理的笔记，旨在方便复习和回顾，并非用作商业用途。

本博客已标明出处，如有侵权请告知，马上删除。

2.4 实战：OutOfMemoryError 异常

在 Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError（下文称 OOM）异常的可能，本节将通过若干实例来验证异常发生的场景，并且会初步介绍几个与内存相关的最基本的虚拟机参数。

本节内容的目的有两个：

• 第一，通过代码验证 Java 虚拟机规范中描述的各个运行时区域存储的内容。
• 第二，希望读者在工作中遇到实际的内存溢出异常时，能根据异常的信息快速判断是哪个区域的内存溢出，知道什么样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何处理。

下文代码的开头都注释了执行时所需要设置的虚拟机启动参数（注释中 “VM Args” 后面跟着的参数），这些参数对实验的结果有直接影响，读者调试代码的时候千万不要忽略。

2.4.1 Java 堆溢出

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

代码限制 Java 堆的大小为 20MB，不可扩展（将堆的最小值 -Xms 参数与最大值 -Xmx 参数设置为一样即可避免堆自动扩展），通过参数 -XX:+HeapDumpOnOutOfMemoryError 可以让虚拟机在出现内存溢出异常时 Dump 出当前的内存堆转储快照以便事后进行分析。

测试代码：

/**
 * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 */
public class HeapOOM {
    static class OOMObject {
    }

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

运行结果：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid10960.hprof ...
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:261)
	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
	at java.util.ArrayList.add(ArrayList.java:458)
	at outofmemoryerror.HeapOOM.main(HeapOOM.java:16)
Heap dump file created [28244549 bytes in 0.106 secs]

Java 堆内存的 OOM 异常是实际应用中常见的内存溢出异常情况。当出现 Java 堆内存溢出时，异常堆栈信息 “java.lang.OutOfMemoryError” 会跟着进一步提示 “Java heap space”。

要解决这个区域的异常，一般的手段是先通过内存映像分析工具对 Dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。

• 如果是内存泄露，可进一步通过工具查看泄露对象到 GC Roots 的引用链。于是就能找到泄露对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息及 GC Roots 引用链的信息，就可以比较准确地定位出泄露代码的位置。
• 如果不存在泄露，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虛拟机的堆参数（-Xmx 与 -Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

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

由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于 HotSpot 来说 ，虽然 -Xoss 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由 -Xss 参数设定。

关于虚拟机栈和本地方法栈，在 Java 虚拟机规范中描述了两种异常：

• 如果线程请求的栈深度大于虚拟机所允许的最大深度，将拋出 StackOverflowError 异常。
• 如果虚拟机在扩展栈时无法申请到足够的内存空间，则拋出 OutOfMemoryError 异常。

这里把异常分成两种情况，看似更加严谨，但却存在着一些互相重叠的地方：当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，其本质上只是对同一件事情的两种描述而已。

StackOverflowError 异常

在笔者的实验中，将实验范围限制于单线程中的操作，尝试了下面两种方法均无法让虚拟机产生 OutOfMemoryError 异常 ，尝试的结果都是获得 StackOverflowError 异常。

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

测试代码（仅作为第一点测试）：

/**
 * VM Args：-Xss128k
 */
public class JavaVMStackSOF {
    private int stackLength = 1;

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

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

运行结果：

stack length：984
Exception in thread "main" java.lang.StackOverflowError
	at outofmemoryerror.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:10)
	at outofmemoryerror.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:11)
......后续异常堆栈信息省略

实验结果表明：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机拋出的都是 StackOverflowError 异常。

OutOfMemoryError 异常

如果测试时不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常。

测试代码：

/**
 * VM Args：-Xss2M（这时候不妨设置大些）
 */
public class JavaVMStackOOM {
    private void dontStop() {
        while (true) {
        }
    }

    public void stackLeakByThread() {
        while (true) {
            Thread thread = new Thread(new Runnable() {
                @Override
                public void run() {
                    dontStop();
                }
            });
            thread.start();
        }
    }

    public static void main(String[] args) throws Throwable {
        JavaVMStackOOM oom = new JavaVMStackOOM();
        oom.stackLeakByThread();
    }
}

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系，或者准确地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。

其实原因不难理解，操作系统分配给每个进程的内存是有限制的，譬如 32 位的 Windows 限制为 2GB。虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存为 2GB（操作系统限制）减去 Xmx（最大堆容量），再减去 MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈 “瓜分” 了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。

这一点读者需要在开发多线程的应用时特别注意，出现 StackOverflowError 异常时有错误堆栈可以阅读，相对来说，比较容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的，所以只能说在大多数情况下）达到 1000〜2000 完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。但是，如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换 64 位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的处理经验，这种通过 “减少内存” 的手段来解决内存溢出的方式会比较难以想到。

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

由于运行时常量池是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。前面提到 JDK 1.7 开始逐步 “去永久代” 的事情，在此就以测试代码观察一下这件事对程序的实际影响。

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

在 JDK 1.6 及之前的版本中，由于常量池分配在永久代内，我们可以通过 -XX:PermSize 和 -XX:MaxPermSize 限制方法区大小，从而间接限制其中常量池的容量。

测试代码：

/**
 * VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        //使用 List 保持着常量池引用，避免 Full GC 回收常量池行
        List<String> list = new ArrayList<>();
        //10MB 的 PermSize 在 integer 范围内足够产生 OOM 了
        int i = 0;
        while (true) {
            list.add(String.valueOf(i++).intern());
        }
    }
}  

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

从运行结果中可以看到，运行时常量池溢出，在 OutOfMemoryError 后面跟随的提示信息是 “PermGen space”，说明运行时常量池属于方法区（HotSpot 虚拟机中的永久代）的一部分。

而使用 JDK 1.7 运行这段程序就不会得到相同的结果，while 循环将一直进行下去。

产生差异的原因：因为在 JDK6 的实现中，HotSpot 使用永久代实现方法区，而从 JDK7 开始 Oracle HotSpot 开始移除永久代，JDK7 中符号表被移动到 Native Heap 中，字符串常量和类引用被移动到 Java Heap 中。在 JDK8 中，永久代已完全被元空间（Meatspace）所取代。

2.4.4 本机直接内存溢出

DirectMemory 容量可通过 -XX:MaxDirectMemorySize 指定，如果不指定，则默认与 Java 堆最大值（-Xmx 指定）一样。

测试代码：

/**
 * VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M
 */
public class DirectMemoryOOM {

    private static final int _1MB = 1024*1024;

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

运行结果：

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

由 DirectMemory 导致的内存溢出，明显特征是在 Heap Dump 文件中不会看见明显的异常，如果发现 Dump 文件很小，而程序直接或间接使用了 NIO，那可以考虑是否由此原因引起。

2.5 本章小结

通过本章的学习，我们明白了虚拟机中的内存是如何划分的，哪部分区域、什么样的代码和操作可能导致内存溢出异常。虽然 Java 有垃圾收集机制，但内存溢出异常离我们仍然并不遥远，本章只是讲解了各个区域出现内存溢出异常的原因，第 3 章将详细讲解 Java 垃圾收集机制为了避免内存溢出异常的出现都做了哪些努力。