在JVM的规范中,整个内存分区除了程序计数器之外,其他的内存区域都有发生OutOfMemoryError(OOM)的可能。本文将会通过几个实例来验证OOM发生的场景以及如何解决。当然,也希望这篇文章可以帮助小伙伴们遇到OOM时,可以快速定位发生OOM的内存区域、哪部分代码可能会导致OOM,并且可以根据定位信息快速解决该异常。
注:对JVM内存分区不熟悉的同学可以参考JVM之Java内存区域
在开始具体的实例分析前,先配置一下JVM启动参数,我用的集成开发环境是IntelliJ IDEA + JDK 1.7:
后续的实例分析也会随时修改该启动参数。
java Heap溢出
java heap是用来存储项目中所有的对象实例,那么,只要不断的创建对象,并且保证GC Roots到这些对象一直存在引用链来避免垃圾回收清除它们,那么在对象数量到达heap的最大容量限制之后就会发生OOM。
案例1
如上图代码所示:
设置java heap的大小为10m,并且不可扩展,通过参数-XX:+HeapDumpOnOutOfMemoryError在JVM出现内存异常时dump当前内存堆快照(快照.hprof文件会默认存储到项目路径下)以便后续分析内存使用情况。
运行结果:
java heap OOM的解决
java heap的OOM在实际应用中非常常见的,要解决这个区域的异常一般先分析内存镜像快照文件,重点确认内存中的对象是否有必要存活,这一步的操作也是为了确认到底是内存泄漏还是内存溢出,分析内存快照镜像文件的方式有很多种,以上述OOM的代码为例,用Eclipse Memory Analyzer分析结果如下图:
分析确定本次OOM的到底是内存泄漏还是内存溢出后:
如果是内存泄漏,进一步查看泄漏对象的引用链,明确泄漏对象是怎么与GC Roots相连而导致垃圾收集器无法自动回收它们。明确引用链后,根据引用链的信息基本就能准备的定位是哪段代码发生了内存泄漏,修改这部分代码;
如果不存在内存泄漏,内存中的对象确实都必须活着,检查JVM堆参数(-Xmx和-Xms)以及服务器内存,看看堆内存是不是还可以稍微调大点儿,同时,检查代码,看看是不是存在生命周期过长的对象,尝试减小程序运行时对内存的消耗。
java Stack溢出
java stack的溢出包含虚拟机栈和本地方法栈。需要注意的是:由于hotspot并不区分虚拟机栈和本地方法栈,JVM启动参数-Xoss(设置本地方法栈大小)是无效的,stack的容量只能由-Xss设定。对于stack,OOM异常有两种:
线程请求栈深度大于JVM所允许的栈深度,抛出StackOverflowError;
JVM扩展栈时无法申请到足够的内存空间,抛出OutOfMemoryError。
在这里只给StackOverflowError案例。
案例2
运行结果:
从运行结果不难看出:
在单个线程下,无论是虚拟机栈容量不够还是栈帧太大,当内存无法分配的时候,虚拟机抛出的都是StackOverflowError。如果在多线程的情况下,不断建立线程其实是可以产生OutOfMemoryError的,但是,这样产生OOM其实与栈空间大小是否足够貌似不存在任何联系,导致这个现象的原因是操作系统分配给每个进程的内存是有限的,如果每个线程分配到的栈容量越大,可建立的线程数量就越小,建立线程时也就越容易把剩下的内存耗尽。所以,判断到底是栈内存不足需要申请额外的内存空间导致的OutOfMemoryError还是操作系统层面导致的OutOfMemoryError很难。因此,在实际工作中,出现StackOverflowError其实比OutOfMemoryError更容易定位问题所在。
方法区溢出
String.inern()是一个native方法,它的作用是:将String对象包含的字符串添加到常量池中。如果常量池中已经包含该字符串,返回代表常量池中该字符串的String对象,否则,将该字符串添加到常量池中并返回该String对象的引用。案例三将调用该native方法,通过-XX:PermSize=3m和-XX:MaxPermSize=3m控制方法区大小来测试方法区溢出。
案例3
运行结果:
同时,我也使用JDK 1.8运行了这段程序,发现while循环会一直进行下去,原因是JDK 1.8废弃了永久代,不能再通过参数-XX:PermSize=3m和-XX:MaxPermSize=3m控制方法区大小。
总结
方法区主要用来存放Class的相关信息,比如类名、访问修饰符、常量池、字段描述、方法描述等。 当然,方法区的溢出也是一种比较常见的内存溢出,一个Class要被回收,判定的条件是非常苛刻的,所以,在经常动态生成大量Class的应用(比如使用CGLib字节码、动态语言、Spring、大量JSP或动态生成JSP文件等)中需要特别注意方法区的回收状况。