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

定义大量的本地变量，增大此方法帧中本地变量表的长度或者设置-Xss 参数减少栈内存容量，这两种操作都会抛出 Stack

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

OverflowError 异常。

/**

• 虚拟机栈 SOF 测试

• <p>

• -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;}}

}

运行结果如下，抛出 StackOverflowError 异常时输出的堆栈深度相应缩小。

所以，如果在单线程的情况下，无论是栈帧太大还是虚拟机栈容量太小，当内存无法再分配的时候，虚拟机抛出的是 StackOverflowError 异常。

如果在多线程下，不断地建立线程可能会产生 OutOfMemoryError 异常。

/**

• 创建线程导致内存溢出异常 注意：windows 平台下执行可能会导致系统卡死

• -Xss2M*/public class JavaVMStackOOM {private void dontStop(){while(true){}}public void stackLeakByThread(){while(true){Thread thread = new Thread(new Runnable() {@Overridepublic void run() {dontStop();}});thread.start();}}

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

运行结果如下：

上面代码导致 OOM 的原因不难理解，操作系统分配给每个进程的内存是有限制的，譬如 32 位的 Windows 限制为 2GB。虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存为 2GB（操作系统限制）减去 Xmx（最大堆容量），再减去 MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽；64 位的 Windows 限制为 8TB，理论上是可以创建很多线程的，但是，谁的机器内存有 8TB？？所以，在其他系统如 Linux，创建多线程时，尽管未达到进程的内存限制，往往也会达到机器的最大内存，导致 OOM。

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

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

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

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

/**

• 运行时常量池导致的内存溢出异常*/public class RuntimeConstantPoolOOM {public static void main(String[] args) {//使用 List 保持常量池引用，避免 Full GC 回收常量池行为 List<String> list = new ArrayList<String>();//10M 的 PermSize 在 integer 范围内足够产生 OOMint i = 0;while (true){list.add(String.valueOf(i++).intern());}}}

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

JDK 1.6 通过设置 VM 参数设置永久代大小 -XX:PermSize=10M -XX:MaxPermSize=10M，运行结果如下：

报错信息为永久代溢出，说明 JDK1.6 时运行时常量池在永久代。

JDK 1.7 设置 VM 参数 -Xmx20m -Xms20m -XX:-UseGCOverheadLimit，这里的-XX:-UseGCOverheadLimit 是关闭 GC 占用时间过长时会报的异常，然后限制堆的大小 -Xmx20m -Xms20m 。

报错信息为堆内存溢出，原因是增加的常量都放到了堆中，所以限制堆内存以后，不断增加常量，导致堆内存溢出。说明 JDK1.7 时运行时常量池在堆中。

在 JDK1.8 中测试，设置 VM 参数 -Xmx20m -Xms20m -XX:-UseGCOverheadLimit，结果和 JDK1.7 相同。

补充一点：如果在上面的 JDK 1.7 或者 JDK1.8 中不通过 VM 参数 -XX:-UseGCOverheadLimit 关闭 GC 占用时间过长时报的异常，即只设置 VM 参数 -Xmx20m -Xms20m ，执行结果如下：

并行/并发回收器在 GC 回收时间过长时会抛出 OutOfMemroyError。过长的定义是，超过 98%的时间用来做 GC 并且回收了不到 2%的堆内存。用来避免内存过小造成应用不能正常工作。

由此可证明，在 JDK1.2 ~ JDK6 的实现中，HotSpot 使用永久代实现方法区，从 JDK7 开始 Oracle HotSpot 开始移除永久代，JDK7 中符号表被移动到 Native Heap 中，字符串常量和类引用被移动到 Java Heap 中。在 JDK8 中，字符串常量依然在堆中，“永久代”完全被元空间(Meatspace)所取代。

运行如下一段代码测试 String.intern（）的返回引用

public class InternMethodTest {public static void main(String[] args) {String str1=new StringBuilder("引用").append("测试").toString();System.out.println(str1.intern()==str1);

String str2=new StringBuilder("ja").append("va").toString();System.out.println(str2.intern()==str2);}}

这段代码在 JDK 1.6 中运行，会得到两个 false，而在 JDK 1.7 中运行，会得到一个 true 和一个 false。产生差异的原因是：在 JDK 1.6 中，intern（）方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用，而由 StringBuilder 创建的字符串实例在 Java 堆上，所以必然不是同一个引用，将返回 false。而 JDK 1.7（以及部分其他虚拟机，例如 JRockit）的 intern（）实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此 intern（）返回的引用和由 StringBuilder 创建的那个字符串实例是同一个。对 str2 比较返回 false 是因为“java”这个字符串在执行 StringBuilder.toString（）之前已经出现过，字符串常量池中已经有它的引用了，不符合“首次出现”的原则，而“计算机软件”这个字符串则是首次出现的，因此返回 true。

方法区用于存放 Class 的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。

方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量 Class 的应用中，需要特别注意类的回收状况。这类场景除了上面提到的程序使用了 CGLib 字节码增强和动态语言之外，常见的还有：大量 JSP 或动态产生 JSP 文件的应用（JSP 第一次运行时需要编译为 Java 类）、基于 OSGi 的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。

4. 本机直接内存溢出

DirectMemory 容量可通过-XX：MaxDirectMemorySize 指定，如果不指定，则默认与 Java 堆最大值（-Xmx 指定）一样，下面代码越过了 DirectByteBuffer 类，直接通过反射获取 Unsafe 实例进行内存分配（Unsafe 类的 getUnsafe（）方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有 rt.jar 中的类才能使用 Unsafe 的功能）。因为，虽然使用 DirectByteBuffer 分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是 unsafe.allocateMemory（）。

import sun.misc.Unsafe;import java.lang.reflect.Field;

/**

• 使用 unsafe 分配本机内存

• -Xmx20M -XX:MaxDirectMemorySize=10M*/public class DirectMemoryOOM {private static final int _1MB = 1024 * 1024;

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