OOM

Love The Way You Lie 2022-01-27 10:13 251阅读 0赞

StackOverflowError是指【线程】的栈内存不足，导致【线程】抛出了StackOverflowError。

内存溢出有3种，我们最熟悉的就是堆内存溢出异常，比如我们**new**一个对象或者数组，如果超出了JVM的heap内存最大限制就会爆出异常

### **堆溢出(OutOfMemoryError:java heap space)----OOM** ###

heap space表示堆空间，堆中主要存储的是**对象**。如果不断的new对象则会导致堆中的空间溢出

可以通过 -Xmx4096M 调整堆的总大小

【情况一】：

[Java][].lang.OutOfMemoryError:**[Java][]heap space**：这种是java堆内存不够，一个原因是真不够，另一个原因是程序中有**死循环**；

如果是java堆内存不够的话，可以通过调整JVM下面的配置来解决：

< jvm-arg>-**Xms**3062m < / jvm-arg>

< jvm-arg>-Xmx3062m < / jvm-arg>

【情况二】

java.lang.OutOfMemoryError: **GC overhead limit exceeded**

【解释】：JDK6新增错误类型，当GC为释放很小空间占用大量时间时抛出；一般是因为堆太小，导致异常的原因，没有足够的内存。

【解决方案】：

1、查看系统是否有使用**大内存的代码或死循环**；

2、通过添加JVM配置，来**限制使用内存**：

< jvm-arg>-XX:-**UseGCOverheadLimit**< /jvm-arg>

【情况三】：

java.lang.OutOfMemoryError: PermGen space：这种是P区内存不够，可通过调整JVM的配置：

< jvm-arg>-XX:MaxPermSize=128m< /jvm-arg>

< jvm-arg>-XXermSize=128m< /jvm-arg>

【注】：

JVM的Perm区主要用于存放Class和Meta信息的,**Class在被Loader时**就会被放到PermGen space，这个区域**成为年老代**，GC在主程序运行期间不会对年老区进行清理，默认是64M大小，当程序需要加载的对象比较多时，超过64M就会报这部分内存溢出了，需要加大内存分配，一般128m足够。

【情况四】：

java.lang.OutOfMemoryError: Direct buffer memory

调整-XX:MaxDirectMemorySize= 参数，如添加JVM配置：

< jvm-arg>-XX:MaxDirectMemorySize=128m< /jvm-arg>

【情况五】：

java.lang.OutOfMemoryError: **unable to create new native thread**

【原因】：Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小了。

【解决】：由于JVM没有提供参数设置总的stack空间大小，但可以设置单个线程栈的大小；而系统的用户空间一共是3G，除了Text/Data/BSS /MemoryMapping几个段之外，Heap和Stack空间的总量有限，是此消彼长的。因此遇到这个错误，可以通过两个途径解决：

1.通过 **-Xss**启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）；

2.通过**-Xms** \-Xmx 两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）。

【情况六】：

java.lang.**StackOverflowError**

【原因】：这也内存溢出错误的一种，即线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小。

【解决】：优化程序设计，减少方法调用层次；调整-Xss参数增加线程栈大小。

### ** 栈溢出(StackOverflowError)** ###

栈是线程私有的，他的生命周期与线程相同，每个方法在执行的时候都会创建一个栈帧，用来存储**局部变量表，操作数栈，动态链接，方法出口灯信息**。局部变量表又包含基本数据类型，对象引用类型（局部变量表编译器完成，运行期间不会变化）  
所以我们可以理解为栈溢出就是方法执行是**创建的栈帧超过了栈的深度**。那么最有可能的就是方法递归调用产生这种结果。

线程的stack是线程独有的，默认大小通常1M，可以通过-Xss来设置，比如-Xss128k,-Xss越大，则线程获得栈内存越大，越难出现栈内存溢出。不过从经验上来讲，1M的栈内存是足够的，如果还出现栈内存溢出，就只能说明程序有问题，常见的就是在线程内过度的进行函数调用，函数调用会消耗栈空间，比如拼命的进行递归调用，这个时候你得考虑在算法上做优化了。

**而JVM虚拟机本质上是操作系统上的一个进程**，所以他也**拥有自己的系统堆空间和栈空间**。  
JVM的栈空间被所有线程分割成一块一块的，每个线程只占用一块。而JVM的栈空间的最小分配单位由-Xss来决定，没错，**-Xss有两个语义， 即定义了每个线程的栈大小，也定义了虚拟机的最小栈内存的分配单位。**我们甚至可以估算出，虚拟机可以创建的最大线程数，即操作系统可以分配给进程的最大栈空间大小除以-Xss的值，就可以得到最大活跃线程数。如果先申请的线程没有栈空间可以分配了就会抛出**OutOfMemoryError**。表示【JVM虚拟机】的栈空间不足，溢出异常。

![20190603145613660.png][]  
参考 [https://blog.csdn.net/u010833547/article/details/78026964?utm\_source=blogkpcl0][https_blog.csdn.net_u010833547_article_details_78026964_utm_source_blogkpcl0]

如何解决：

我们需要使用参数 **-Xss**去调整JVM栈的大小(单个线程栈大小)

进一步

** OOM**

1， OutOfMemoryError异常

除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，

Java Heap 溢出

一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess

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

出现这种异常，一般手段是先通过**内存映像分析工具**(如Eclipse Memory Analyzer)对**dump**出来的**堆转存快照**进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

如果是**内存泄漏**，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。

如果不存在泄漏(内存溢出)，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。(死循环)

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

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。

如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常

这里需要注意**当栈的大小越大可分配的线程数就越少**。

3， 运行时常量池溢出

异常信息：java.lang.OutOfMemoryError:PermGen space

**如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native方法**。该方法的作用是：如果池中已经包含一个等于此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量池的容量。

4， 方法区溢出

方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。

异常信息：java.lang.OutOfMemoryError:PermGen space

方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zOTU5Mzk4NQ_size_16_color_FFFFFF_t_70][]

**java中什么是内存泄漏?(**Memory Leak**)**

在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。

通过分析，我们得知，对于C++，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。通过这种方式，Java提高了编程的效率。

对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义， 该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。

**详细Java中的内存泄漏**

**1.Java内存回收机制**

不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，这样重新分配了内存空间。

**2.Java内存泄漏引起的原因**

内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。

Java内存泄漏的根本原因是什么呢？**长生命周期的对象持有短生命周期对象的引用**就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是Java中内存泄漏的发生场景。具体主要有如下几大类：

**1、静态集合类引起内存泄漏：**

像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

Static Vector v = new Vector(10);
    for (int i = 1; i<100; i++)
    {
    Object o = new Object();
    v.add(o);
    o = null;
    }

在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。

**2、当集合里面的对象属性被修改后，再调用remove()方法时不起作用。**

public static void main(String[] args)
    {
    Set<Person> set = new HashSet<Person>();
    Person p1 = new Person("唐僧","pwd1",25);
    Person p2 = new Person("孙悟空","pwd2",26);
    Person p3 = new Person("猪八戒","pwd3",27);
    set.add(p1);
    set.add(p2);
    set.add(p3);
    System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!
    p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变
    set.remove(p3); //此时remove不掉，造成内存泄漏
    set.add(p3); //重新添加，居然添加成功
    System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!
    for (Person person : set)
    {
    System.out.println(person);
    }
    }

注意 : hashset底层使用的是hashmap , 存入的数组作为key(value不使用) , 因此在数值非final类型时 , 应自己实现对应的equals()方法和hashcode()方法

**3、监听器**

在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

**4、各种连接**

比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。(直接用spring管理就可以不用操心这个)

**5、内部类和外部模块的引用**

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：

public void registerMsg(Object b);

这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。(...)

**6、单例模式**

不正确使用单例模式是引起内存泄漏的一个常见问题，单例对象在初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏，考虑下面的例子：

class A{
    public A(){
    B.getInstance().setA(this);
    }
    ....
    }
    //B类采用单例模式
    class B{
    private A a;
    private static B instance=new B();
    public B(){}
    public static B getInstance(){
    return instance;
    }
    public void setA(A a){
    this.a=a;
    }
    //getter...
    }

显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况

**内存泄漏和内存溢出之间的不同点**：1) **内存泄露是导致内存溢出的原因之一**，内存泄露积累起来将导致内存溢出。2) 内存泄露可以通过完善代码来避免，内存溢出可以通过调整配置来减少发生频率，但无法彻底避免。

一个实例 参考 :

[一个Java内存泄漏的排查案例][Java 1]

[Java]: https://link.jianshu.com?t=http://lib.csdn.net/base/java
[20190603145613660.png]: /images/20220127/7fd3c14b48cb438f92c7304d914061b3.png
[https_blog.csdn.net_u010833547_article_details_78026964_utm_source_blogkpcl0]: https://blog.csdn.net/u010833547/article/details/78026964?utm_source=blogkpcl0
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zOTU5Mzk4NQ_size_16_color_FFFFFF_t_70]: /images/20220127/89a52eace4044560811cc7cfa52c1633.png
[Java 1]: https://juejin.im/entry/5b2c9a376fb9a00e5326e05e?utm_source=gold_browser_extension