1.概述
在Java虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError（OOM）异常的可能，本文将通过若干实例来验证异常发生的场景，并且会初步介绍几个与内存相关的最基本的虚拟机参数。
本文有两个目的：第一，通过代码验证Java虚拟机规范中描述的各个运行时区域存储的内容；第二，希望读者在工作中遇到实际的内存溢出异常时，能根据异常的信息快速判断是哪个区域的内存溢出，知道什么样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何处理。

JVM内存结构布局和相应的控制参数.jpg

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

import java.util.ArrayList;
import java.util.List;

/**
 * VM Args:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 * 
 * @author Davince
 *
 */
public class HeapOOM {
    static class OOMObject {
    }
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();
        while (true) {
            list.add(new OOMObject());
        }
    }
}

输出结果如下：
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid72568.hprof ...
Heap dump file created [28138241 bytes in 0.171 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 com.nwpu.davince.jvm.HeapOOM.main(HeapOOM.java:21)

要解决这个区域的异常，一般的手段是先通过内存映像分析工具（Memory Analyzer Tool,MAT）对Dump出来的堆转储快照进行分析，重点确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。
如果是内存泄漏，可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息及GC Roots引用链的信息，就可以比较准确地定位出泄漏代码的位置。
如果不存在泄漏，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（最大堆-Xmx和最小堆-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

3.虚拟机栈和本地方法栈溢出
由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

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

/**
 * VM Args:-Xss128k
 * 
 * @author Davince
 *
 */
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:995
Exception in thread "main" java.lang.StackOverflowError
    at com.nwpu.davince.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:14)
    at com.nwpu.davince.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:15)
    at com.nwpu.davince.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:15)
......后续异常堆栈信息省略

/**
 * VM Args:-Xss2M
 * 
 * @author Davince
 *
 */
public class JavaVMStackOOM {
    private void dontStop() {
        while(true) {
        }
    }   
    public void stackLeakByThread() {
        while (true) {
            Thread thread = new Thread(new Runnable() {
                public void run() {
                    dontStop();
                }
            });
            thread.start();
        }
    }
    public static void main(String[] args) {
        JavaVMStackOOM oom = new JavaVMStackOOM();
        oom.stackLeakByThread();
    }
}
输出结果如下：
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

4.方法区和运行时常量池溢出
由于运行时常量池也是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。前面也提到JDK1.7开始逐步“去永久代”的事情，在此就以测试代码观察一下这件事情对程序的实际影响。
String.intern()是一个Native方法，它的作用是：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。在JDK1.6及之前的版本中，由于常量池分配在永久代内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区大小，从而间接限制其中常量池的容量。

import java.util.ArrayList;
import java.util.List;
/**
 * VM Args:-XX:PermSize=10M -XX:MaxPermSize=10M
 * 
 * @author Davince
 *
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        // 使用List保持常量池引用，避免Full GC回收常量池行为
        List<String> list = new ArrayList<String>();
        int i = 0;
        while (true) {
            list.add(String.valueOf(i++).intern());
        }
    }
}
输出结果如下：
Exception in thread "main" java.lang.OutOfMemoryError:PermGen space
  at java.lang.String.intern(Native Method)
  at com.nwpu.davince.jvm.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:19)

注：此处代码使用JDK1.6版本调试，如果使用JDK1.7及以上版本运行这段程序while循环将一直进行下去。

关于字符串常量池的实现问题，还可以引申出一个更有意思的影响，如下代码所示。

/**
 * @author Davince
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        String str1 = new StringBuilder("a").append("b").append("c").toString();
        System.out.println(str1.intern() == str1);
        String str2 = new StringBuilder("d").append("e").append("f").toString();
        System.out.println(str2.intern() == str2);
    }
}
输出结果如下：
true
true

上述这段代码在JDK1.6中运行会得到两个false，而在JDK1.8中运行会得到两个true。产生差异的原因是：在JDK1.6中，intern()方法会把首次遇到的字符串实例复制到永久代，返回的也是永久代中这个字符串实例的引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是同一个引用，将返回false。而在JDK1.8中的intern()方法实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。

5.本机直接内存溢出
DirectMemory容量可通过-XX:MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值（-Xmx指定）一样。

import java.lang.reflect.Field;

/**
 * VM Args:-Xmx20M -XX:MaxDirectMemorySize=10M
 * @author Davince
 *
 */
public class DirectMemoryOOM {
    private static final int _1MB = 1024*1024;  
    public static void main(String[] args) {
        Field unsafeField = Unsafe.class.getDeclaredField()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe)unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);
        }
    }
}
输出结果如下：
Exception in thread "main" java.lang.OutOfMemoryError
  at sun.misc.Unsafe.allocateMemory(Native Method)
  at com.nwpu.davince.jvm.DirectMemoryOOM.main(DirectMemoryOOM.java:14)

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