面试JVM(六)OOM

OutOfMemoryError异常:

目录

1:java堆溢出

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

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

4:本地直接内存溢出


1:java堆溢出

要同时满足两个条件:

  1. 堆大小固定,不可扩展
  2. 不断创建对象,并保持对象存活不被回收

深入理解java虚拟机原文:

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

下面代码限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。public class HeapOOM {
    static class OOMObject{}
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<HeapOOM.OOMObject>();
        while(true) {
            list.add(new OOMObject());
       }
    }   
}

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时,异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。

        要解决这个区域的异常,一般的手段是先通过内存映像分析工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清除到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。下图显示了使用Eclipse Memory Analyzer打开的堆转储快照文件。

如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收他们的。掌握了泄漏对象的类型信息及GC Roots引用链的信息,就可以比较准确的定位出泄漏代码的位置。

        如果不存在泄漏,换句话说,就是内存中的对象确实还必须存活着,那就应当检查虚拟机的堆参数(-Xmx与-Xms),与机器物理内存对比看是否还可以调大,从代码上检查虚拟机的堆参数(-Xmx与-Xms),与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少的程序运行期的内存消耗。

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

一、在 Java 虚拟机规范中,对虚拟机栈这个区域规定了两种异常状况:

(1)如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError 异常; 
(2)如果虚拟机栈可以动态扩展时无法申请到足够的内存空间时会抛出 OutOfMemoryError 异常。 

在单线程下,无论是栈帧太大还是虚拟机栈容量太小,当内存无法分配时,虚拟机都抛出StackOverflowError 异常。

如果测试时不限于单线程,通过不断地建立线程的方式倒是可以产生内存溢出异常。

为什吗多线程的情况下就会产生OOM,这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系,或者准确地说,在这种情况下,给每个线程的栈分配的内存越大,反而越容易产生内存溢出异常。

原因其实不难理解,操作系统分配给每个进程的内存是有限制的,譬如 32 位的 Windows 限制为 2GB。虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存为 2GB(操作系统限制)减去 Xmx(最大堆容量),再减去 MaxPermSize(最大方法区容量),程序计数器消耗内存很小,可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内,剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大,可以建立的线程数量自然就越少,建立线程时就越容易把剩下的内存耗尽。

更简单理解的就是:有一个操作系统为2G,我们分配给两个线程,每个800M,也就还剩400M,这样的话,有一个线程不够用的话,就会在400里边申请,所以如果剩下的越多,出现OOM的可能性越小,如果每个分配950M,这样就剩100M,这样的话出现OOM的可能性就更大。如果在增加线程,系统对每一个线程非配的内存是一定的,所以剩下的内存更少,这样的话,出现OOM的可能更大,但这都是相对而说。

遇到OOM这时候我们应该怎么做:

如果是建立过多线程导致的内存溢出,在不能减少线程数或者更换 64 位虚拟机的情况下,就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的经验,这种通过“减少内存”的手段来解决内存溢出的方式会比较难以想到。
 

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

永久代溢出——常量池溢出 
要模拟常量池溢出,可以使用String对象的intern()方法。如果常量池包含一个此String对象的字符串,就返回代表这个字符串的String对象,否则将String对象包含的字符串添加到常量池中。

4:本地直接内存溢出

DirectMemory可以通过-XX:MaxDirectMemorySize指定,如果不指定,默认与Java堆的最大值(-Xmx指定)一样。 

https://www.cnblogs.com/zhuxing/articles/1247621.html

总结: 
栈内存溢出:程序所要求的栈深度过大。 
堆内存溢出: 分清内存泄露还是 内存容量不足。泄露则看对象如何被 GC Root 引用,不足则通过调大-Xms,-Xmx参数。 
永久代溢出:Class对象未被释放,Class对象占用信息过多,有过多的Class对象。 
直接内存溢出:系统哪些地方会使用直接内存。
 

猜你喜欢

转载自blog.csdn.net/lettyisme/article/details/85050393