OOM问题分析

一、背景

　　在实际的开发中，性能问题的分析一直是运维团队的痛点，无论是缓慢内存溢出还是迅速的内存爆炸，对系统和业务的破坏都是快速而巨大的，此贴分享下简单的分析内存问题的经验。

二、相关名词　

　　分代：根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，扬长避短也。

Young（年轻代）
年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor复制过来的对象。而且，Survivor区总有一个是空的。
Tenured（年老代）
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
Perm（持久代）
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

　　GC的基本概念

　　gc分为full gc 跟 minor gc（Young GC也就是Minor GC），当每一块区满的时候都会引发gc。

Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就触发了Scavenge GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。
Full GC
对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC：

上一次GC之后Heap的各域分配策略动态变化

System.gc()被显示调用

Perm域被写满

Tenured被写满

　　内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

　　内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。其实说白了就是该内存空间使用完毕之后未回收。

　　注：此部分内容参考https://blog.csdn.net/jethai/article/details/52345074，感谢原作者

三、OOM场景模拟

　　由于Object对象无限增长导致的内存溢出代码示例，以及运行结果

public class OutofMemeorySample {

    public static voidmain(String[] args) {

       headOutOfMemory();

    }

    static void headOutOfMemory(){

        long count= 0;

        try {

           List<Object> objects = newArrayList<Object>();

           while (true) {

               count++;

               objects.add(new Object());

           }

        } catch(Throwable ex) {

           System.out.println(count);

           ex.printStackTrace();

        }

    }

}

　　找出运行中的进程id，并生成dump文件，该部分操作详细请见https://www.cnblogs.com/jiyukai/p/9292102.html

　　在JDK自带的分析工具jvisualvm中装入dump文件，通过工具分析堆栈内存情况

　　在jvisualvm中可以查看到dump的基本信息，类实例及占比等情况

四、其他案例

本地设置的最大堆内存是800M左右，代码里面是往一个List里面疯狂加数据，直到撑爆堆内存，得到的监控内容是这样的：

分析：红框框出的部分是发生堆内存溢出时的情形，已使用的堆大小（蓝色部分）并没有增长特别明显，但是申请的堆的大小（黄色部分）从默认的400多兆急速上涨，涨到800M，然后内存溢出，然而使用的堆大小依然没怎么增长。

所以，dump文件中的实例列表其实是反映了使用的堆的情况，而使用的堆内存并没有达到预先设置的最大堆内存，只是在申请堆内存的过程中超出了预先设置的最大堆内存，然后内存溢

此处参考：https://blog.csdn.net/lkforce/article/details/60878295，感谢原作者

巴特西

OOM问题分析

最新文章

热门文章