2.4.2 虚拟机栈与本地方法栈溢出
由于在HotSpot虚拟机中并不区分虚拟机栈1和本地方法栈，因此，对于HotSpot来说，虽然 -Xoss 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：
- 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出
StackOverflowError异常。 - 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出
OutOfMemoryError异常。
package cn.archessay.jvm;
/**
* VM args: -Xss160k
*/
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 t) {
System.out.println("stack length: " + oom.stackLength);
t.printStackTrace();
}
}
}
运行结果：
stack length: 772
java.lang.StackOverflowError
at cn.archessay.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:11)
at cn.archessay.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:12)
at cn.archessay.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:12)
at cn.archessay.jvm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:12)
...
实验结果表明：在单线程下，无论是由于栈帧2太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。
但是，如果测试时不限于单线程，通过不断地创建线程的方式倒是可以产生内存溢出异常，如代码清单2-5所示。
在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
其实原因不难理解，操作系统分配给每个进程的内存是有限的，譬如32位的Windows限制为2GB。虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值。剩余的内存为2GB（操作系统限制）减去Xmx（最大堆容量），再减去MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。
package cn.archessay.jvm;
import java.util.concurrent.TimeUnit;
/**
* VM args: -Xss2M
*/
public class JavaVMStackOOM {
private void dontStop() {
while (true) {
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public void stackLeakByThread() {
while (true) {
Thread thread = new Thread(new Runnable() {
@Override
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
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at cn.archessay.jvm.JavaVMStackOOM.stackLeakByThread(JavaVMStackOOM.java:28)
at cn.archessay.jvm.JavaVMStackOOM.main(JavaVMStackOOM.java:34)
2.4.3 方法区和运行时常量池溢出
在JDK1.7+中，字符串常量池的实现有这么一个有趣的问题：
package cn.archessay.jvm;
/**
* JDK1.7+
*/
public class RuntimeConstantPoolOOM {
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);
}
}
上述代码在JDK1.6中运行，会得到两个false，而在JDK1.7+中运行的执行结果为true、false。
产生差异的原因是：在JDK1.6中，intern()方法会把首次遇到的字符串实例复制到永久代3中，返回的也是永久代中这个字符串实例的引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是同一个引用，将返回false。
而在JDK1.7+（以及部分其它虚拟机，例如JRockit）的intern()实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。对于str2比较返回false是因为“java”这个字符串在执行new StringBuilder("ja").append("va").toString()之前已经出现过，字符串常量池中已经有它的引用了，不符合“首次出现”的原则，而“计算机软件”这个字符串是首次出现的，因此返回true。