首页 > 代码库 > java虚拟机内存溢出各种场景总结

java虚拟机内存溢出各种场景总结

java堆溢出

java堆用于存储对象实例,只要不断地创建对象,并且保证gc roots到对象之间有可达路径来避免垃圾回收机制来清楚这些对象,那么在 对象到达最大堆的容量限制后就会产生内存溢出溢出。

异常:java.lang.OutOfMemoryError: java heap space

要解决这个区域的异常,首先要区分是出现了内存泄露(Memory Leak)还是内存溢出(Memory OverFlow)。 解决方式:如果是内存泄露,通过工具(eclipse memory analyzer)查看泄露对象到gc roots的引用链。于是就能找到泄露对象是通过怎样的路径与gc roots相关联 并导致垃圾回收器无法自动回收它们的。掌握了泄露对象的类型信息及gc roots引用链的信息,就可以准确的找出泄露代码的位置。 如果不存在泄露,换句话说,就是内存中的对象确实都还必须存活着,那就应当检查虚拟机的堆参数(-Xmx与-Xms)与机器物理内存是否还可以调大,从代码上检查 是否存在某些对象生命周期过长,持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

 

虚拟机栈和本地方法栈溢出

-Xoss参数设置本地方法栈大小 -Xss 参数设置栈容量

-Xoss参数是否有效,取决于jvm采用了哪种虚拟机,譬如如果采用HotSpot虚拟机,-Xoss参数(无效),这样虚拟机栈和本地方法栈通过栈容量控制。

关于虚拟机栈和本地方法栈,在java虚拟机规范中描述了两种异常: 如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常。 如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。

在单个线程下,无论是由于栈帧太大还是虚拟机容量太小,当内存无法分配的时候,虚拟机抛出的都是StackOverflowError异常。 如果不限于单线程,在这种情况下,为每个线程的栈分配的内存越大,反而越容易产生内存溢出异常。

如果建立过多线程导致内存溢出,在不能减少线程数或者更换64位虚拟机的情况下,就只能通过减少最大堆和减少栈容量来换取更多的线程。

 

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

运行时常量池是方法区的一部分。 从JDK1.7开始逐步“去永久代”,我们这里讨论1.6版本,在1.6版本中,由于常量池分配在永久代内,我们可以 通过-XX:PermSeize和-XX:MaxPermSeize限制方法区大小,从而间接限制其中常量池的容量。

异常:java.lang.OutOfMemoryError: PermGen space

方法区用于存放Class的相关信息,如类名,访问修饰符,常量池,字段描述,方法描述等。 方法区异常是一种常见的内存溢出异常,一个类要被垃圾收集器回收掉,判定条件是比较苛刻的。在经常动态生成大量Class的应用中,需要特别注意类的回收情况。

 

本机直接内存溢出

异常:java.lang.OutOfMemoryError

DirectMemory容量可通过-XX:MaxDirectMemorySize,如果不指定,默认与java堆最大值(-Xmx指定)一样。 由DirectMemory导致的内存溢出,一个明显的特征是在Heap Dump文件中不会看见明显的异常,如果发现OOM之后Dump文件很小,而程序中又直接或间接使用了NIO,那就可以 考虑检查一下是不是这方面的原因。

 

java虚拟机内存溢出各种场景总结