本文主要是介绍【深入理解JVM】：OutOfMemoryError异常总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
JVM内存区域中，除了程序计数器外，其他几个运行时区域都有可能发生OutOfMemoryError（OOM）异常。本文对OOM异常进行总结，通过代码验证JVM规范中描述的运行时区域存储的内容；了解可能导致这些区域OOM异常的代码，能够在工作中根据异常代码对内存哪一出区域进行定位。
基于Sun的HotSpot虚拟机，在Eclipse中Run/Arguments中可以进行虚拟机启动参数的设置，这些参数对实验结果有直接影响，不能忽略。
Java堆溢出
Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，对象数量达到最大堆容量限制，则发生溢出。
限制Java堆的大小为20MB，最小值和最大值相同（不可扩展）。当虚拟机出现内存溢出异常时Dump出当前的内存堆转储快照以便事后分析。
package com.jvm.OutOfMemoryError;import java.util.List;
import java.util.ArrayList;/*** Java堆溢出* VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError*/public class HeapOOM {public static void main(String[] args) {List<OOMObject> list = new ArrayList<OOMObject>();while(true) {// list保留引用，避免Full GC 回收 list.add(new OOMObject());}}static class OOMObject {}
}
运行结果：
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid7768.hprof ...
Heap dump file created [27987840 bytes in 0.142 secs]这种异常比较常见，一般先通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，确实是内存泄露还是内存溢出。
- 内存泄露
查看泄露对象到GC Roots的引用链，定位泄露代码位置。 - 内存溢出
如果不存在泄露，即内存中的对象确实都还必须活着，检查JVM堆参数（-Xmx与-Xms），调大参数，检查代码是否存在某些对象生命周期过长，持有状态过长的情况，减少程序运行期的内存消耗。
虚拟机栈和本地方法栈溢出
HotSpot不区分虚拟机栈和本地方法栈，栈容量只能由-Xss参数设定。
- StackOverFlow：线程申请的栈深度超过允许的最大深度
- OutOfMemoryError： 虚拟机扩展时无法申请到足够的内存空间
StackOverFlow的情况：递归调用方法，定义大量的本地变量，增大此方法帧中本地变量表的长度。
package com.jvm.OutOfMemoryError;
/*** 虚拟机栈和本地方法栈溢出 StackOverFlow* VM Args：-Xss128k*/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 e) {System.out.println("stack length: " + oom.stackLength);throw e;}}}
运行结果：
stack length: 999
Exception in thread "main" java.lang.StackOverflowErrorat com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26)at com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26)at com.jvm.OutOfMemoryError.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:26)......OutOfMemoryError：多线程下的内存溢出，与栈空间是否足够大并不存在任何联系。为每个线程的栈分配的内存越大（参数-Xss），那么可以建立的线程数量就越少，建立线程时就越容易把剩下的内存耗尽，越容易内存溢出。在这种情况下，如果不能减少线程数目或者更换64位虚拟机时，减少最大堆和减少栈容量能够换区更多的线程。
注意：Windows平台虚拟机中，Java的线程映射到操作系统的内核线程上执行，下面代码执行可能造成系统假死！
package com.jvm.OutOfMemoryError;
/*** 虚拟机栈和本地方法栈溢出* * !!!!!注意!!!!!* 运行该代码可能造成系统假死！！！！* * VM Args：-Xss2M（可以适当大一点）*/public class JavaVMStackOOM {private void dontStop() {while(true) {}}// 多线程方式造成栈内存溢出 OutOfMemoryErrorpublic 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();}
}
方法区和运行常量池溢出
运行时常量池
JDK1.7开始逐步“去永久代”，下面的讨论可以测试下实际影响。
String.intern()是一个Native方法，它的作用是：如果运行时常量池中已经包含一个等于此String对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此String内容相同的字符串，并返回常量池中创建的字符串的引用。JDK7的intern()方法的实现有所不同，当常量池中没有该字符串时，不再是在常量池中创建与此String内容相同的字符串，而改为在常量池中记录堆中首次出现的该字符串的引用，并返回该引用。
在JDK1.6之前，常量池分配在永久代，以下代码在JDK1.6下运行才回发生内存溢出，如果在JDK1.7及其之后的版本运行，则是死循环：
package com.jvm.OutOfMemoryError;import java.util.ArrayList;
import java.util.List;/*** 运行时常量池溢出* * jdk1.7 及其以后的版本已经“去永久代”，jdk1.6之前的环境下运行才会出现溢出* -XX:PermSize=10M -XX:MaxPermSize=10M （间接指定常量池容量大小）*/public class RuntimeConstantPoolOOM {public static void main(String[] args) {List<String> list = new ArrayList<String>();int i = 0;while(true) {// list保留引用，避免Full GC 回收 list.add(String.valueOf(i++).intern());}}
}
运行结果：
Exception in thread "main" java.lang.OutOfMemoryError: PermGen spaceat java.lang.String.intern(Native Method)......方法区
方法区用于存放Class的相关信息，如果运行时产生大量的类去填满方法区，就可能发生方法区的内存溢出。 例如主流框架Spring、Hibernate对大量的类进行增强时，利用CGLib字节码生成动态类；大量JSP或动态JSP(JSP第一次运行时需要编译为Java类）。
下面为CGLib动态生成类导致的方法区溢出：
package com.jvm.OutOfMemoryError;import java.lang.reflect.Method;
import com.jvm.OutOfMemoryError.HeapOOM.OOMObject;import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;/*** 方法区溢出* -XX:PermSize=10M -XX:MaxPermSize=10M*/public class JavaMethodAreaOOM {public static void main(String[] args) {while(true) {Enhancer enhancer = new Enhancer();enhancer.setSuperclass(OOMObject.class);enhancer.setUseCache(false);enhancer.setCallback(new MethodInterceptor() {@Overridepublic Object intercept(Object obj, Method m, Object[] objs, MethodProxy proxy) throws Throwable {// TODO Auto-generated method stubreturn proxy.invokeSuper(obj, objs);}});enhancer.create();}}
}
运行结果：
Caused by: java.lang.OutOfMemoryError: PermGen spaceat java.lang.ClassLoader.defineClass1(Native Method)......本地直接内存溢出
Java虚拟机可以通过参数-XX:MaxDirectMemorySize设定本机直接内存可用大小，如果不指定，则默认与java堆内存大小相同。JDK中可以通过反射获取Unsafe类(Unsafe的getUnsafe()方法只有启动类加载器Bootstrap才能返回实例)直接操作本机直接内存。通过使用-XX:MaxDirectMemorySize=10M，限制最大可使用的本机直接内存大小为10MB。
import java.lang.reflect.Field;public class DirectMemoryOOM {private static final int _1MB = 1024 * 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 直接想操作系统申请内存unsafe.allocateMemory( _1MB );}}
}运行结果：
Exception in thread "main" java.lang.OutOfMemoryErrorat sun.misc.Unsafe.allocateMemory(Native Method)......这种异常的明显特征是在Heap Dump文件中看不见明显的异常。如果OOM之后Dump的文件比较小，程序中直接或间接用到了IO/NIO，可以考虑是否是这方面的原因。
参考
1、周志明，深入理解Java虚拟机：JVM高级特性与最佳实践，机械工业出版社
这篇关于【深入理解JVM】：OutOfMemoryError异常总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
