根据java虚拟机规范中的描述，除了程序计数器，运行时数据区的其他几个区域都会发生OutOfMemoryError（简称OOM）异常，下面通过实例来正真感受一下什么情况下这几个区域会发生OOM异常。
java堆溢出：
java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间的有可达路径来避免回收机制清除这些实例，那么这些对象数量到达最大堆的容量限制后就会产生内存异常。我们通过-Xmx设置最大堆，-Xms设置最小堆，-XX:+HeapDumpOnOutOfMemoryError生成内存堆存储快照。
运行结果：
java.lang.OutOfMemoryError: Java heap space
之后我们再通过内存分析映像分析工具对Dump出来的堆转储快照进行分析，这里我用的是JProfiler进行分析，重点是确定内存中的对象是否是必要的，也就是要分清楚到底是内存泄露（Memory Leak）还是内存溢出（Memory Overflow）。 如果是内存泄露，可以进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象通过怎样的路径与GC Roots相关联并且导致垃圾收集器无法自动回收它的。 如果不存在内存泄露，就是内存中的对象确实都还存活着，那就应当检查虚拟机的堆参数（-Xms与-Xmx），与机器物理内存对比看是否可以调大，从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况。尝试减少程序运行期的内存消耗。
虚拟机栈和本地方法栈溢出：
由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由-Xss参数设置。关于虚拟机栈和本地方法栈，在java虚拟机规范中描述了两种异常：
如果线程请求的栈深度大于虚拟机所允许的最大深度，就抛出StackOverflowError异常。
-
如果虚拟机在扩展是无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
这里把异常分为两种，但是实际情况是：当栈空间无法继续分配时，到底是内存不足，还是已使用的栈空间太大，其本质上只是对同一件事情的良好总描述而已。
下面分析的两种情况都是抛出StackOverflowError。
通过-Xss参数减少栈容量。结果：抛出StackOverflowError异常时异常输出的堆栈深度相应减少。
定义大量的本地变量，增加此方法帧中本地变量表的长度。结果：抛出StackOverflowError异常时输出的堆栈深度相应减少。
public class StackTest {
private int stackLength=1;
public static void main(String[] args) throws Throwable{
StackTest stackTest = new StackTest();
try {
stackTest.stackLeak();
}catch (Throwable e){
System.out.println("栈深度:"+stackTest.stackLength);
throw e;
}
}
public void stackLeak(){
stackLength++;
stackLeak();
}
}
运行结果：
Exception in thread "main" java.lang.StackOverflowError
实验结果表明：在单线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。
如果测试的是多线程，通过不断创建线程的方式倒是可以产生内存溢出异常。但是这种情况的内存溢出异常与栈空间是否足够大并不存在任何联系，或者准确的说，这种情况下，为每个线程创建的栈内存越大，就越容易产生内存溢出异常。
原因是操作系统为每个进程分配的内存是有限的，譬如32位windiws限制为2GB。虚拟机提供参数控制java堆和方法区的内存最大值。剩余的内存是2GB减去最大堆内存和最大方法区内存，程序计数器的内存很小可以直接忽略。如果虚拟机本身消耗的内存不计算在内，剩余的内存就是虚拟机栈和本地方法栈的空间。每个线程分配到的栈容量越大，可以建立的线程数就越少，建立线程就容易把剩余的内存耗尽。
另外，对于StackOverflowError异常来说，在使用虚拟机默认的参数的情况下，栈的深度大多数情况是可以达到1000-2000的，对于正常的方法调用，这个深度应该是够用了。但是如果是建立线程过多导致的内存溢出，在不能减少线程或者更换64位虚拟机的情况下，就只能通过减少最大堆内存或者减少栈容量来换取更多的线程。
//此段代码会造成系统假死，慎重尝试
public class StackTest {
public static void main(String[] args) {
StackTest stackTest = new StackTest();
stackTest.stackLeak();
}
public void stackLeak(){
while(true){
new Thread(new Runnable() {
@Override
public void run() {
while(true){
}
}
}).start();
}
}
}
方法区和运行时常量池溢出：
在jdk7之前，由于运行时常量池在方法区中，我们可以通过设置-XX:permSize和-XX:MaxPermSize参数来设置方法区大小，从而限制运行时常量池的大小。在jdk7之前，会抛出PermGen space的OOM异常，在jdk7之后，运行时常量池被移出了方法区（放入了堆中），所以不再使用-XX:PermSize和-XX:MaxPermSize参数，我们通过设置-Xms10M，-Xmx10M来验证运行时常量区被移到了堆中。
public class PermTest {
public static void main(String[] args) {
int i=0;
while(true){
List<String> list = new ArrayList<>();
list.add(String.valueOf(i++).intern());
}
}
}
运行结果：
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
在这里，我们提一下String的intern方法。在jdk7之前，new一个String对象，会在堆中创建该对象，如果使用intern()方法，会将该对象的值拷贝到常量池中，并且返回常量池中该字符串的引用。但是jdk7的时候，new一个String对象，会在堆中创建该对象，如果使用intern()方法，不在将数据拷贝到常量池中，而是生成一个对当前对昂的引用，并且返回其引用。
public static void main(String[] args) {
String str2 = new String("he")+new String("llo");
str2.intern();
String str1 = "hello";
System.out.println(str2==str1);//true
}
intern方法允许我们的运行的时候动态添加字符串到运行时常量池中，所以可能会造成OOM异常。
在方法区中存放着class的相关信息，常量，静态变量，即时编译器便利以后的代码等数据。所以我们可以通过产生大量的类来实现方法区的OOM。动态产生大量类的方法有很多，java的动态代理，CJLib动态代理。为了方便起见，在这里我使用CJLib来实现动态代理生成大量的类。另外，要注意的是，从jdk7开始就开始废弃永久代，到jdk8彻底移除了永久代，替代其的是元空间（Matespace），元空间是使用本地内存存储，我们用-XX:MaxMetaspaceSize和-XX:MatespaceSize参数限制元空间的大小。
public class Test {
static class OOMObject{
}
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invoke(obj, args);
}
});
enhancer.create();
}
}
}
运行结果：
Caused by: java.lang.OutOfMemoryError: Metaspace
要注意的是，jdk8之后，运行时常量池移到了方法区中，永久代被移除，由元数据代替，元空间是本地内存存储。相对来说，如果是元空间溢出导致的OOM，我们很容易就会发现，最简单粗暴的处理方式就是增加元空间的大小。
本机直接内存溢出：
DirectMemory容量可以通过-XX:MaxDirectMemorySize指定，如果不止顶，则和java最大堆的大小一样，下面的例子通过Unsafe实例今次那个内存分配（Unsafe类getUnsafe()方法限制里只有引导类加载器才可以返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。芮然可以使用DirectByteBuffer分配内存也会抛出溢出异常，但是它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常。真正申请内存分配的是Unsafe.allocateMemory().
public class DirectMemoryTest {
private final static int _iMB=1024 * 1024;
public static void main(String[] args) throws IllegalAccessException {
Field declaredField = Unsafe.class.getDeclaredFields()[0];
declaredField.setAccessible(true);
Unsafe o = (Unsafe) declaredField.get(null);
while (true){
o.allocateMemory(_iMB);
}
}
}
运行结果：
Exception in thread "main" java.lang.OutOfMemoryError
由DirectMemory导致的内存溢出有一个明显的特点，就是在Heap Dump中不会发现明显的异常。如果发现文件很小，并且项目找中有直接或者近接的使用了NIO，则很有可能是直接内存溢出了。
以上内容主要参考《深入理解java虚拟机》的内容。如有错误，欢迎指出。
