Java堆溢出产生原因和排查工具MAT的使用

Java堆溢出(OOM for Heap)

Java虚拟机内存模型中堆用于存储对象实例，当GC Roots到创建的对象之间有可达路径时，就可以避免垃圾回收机制回收这些对象，那么只要不断地创建这样的对象，当数量到堆的容量限制后就会产生堆内存溢出异常(OOM for Heap)。

获取Heap Dump文件

Heap Dump 是一个 Java 进程在某个时间点上的内存快照。 Heap Dump 是有着多种格式的。 不过总体上Heap Dump 在触发快照的时候都保存了 java 对象和类的信息。通常在写 Heap Dump 文件前会触发一次 FullGC，所以 Heap Dump 文件中保存的是 FullGC 后留下的对象信息。
一般在 Heap Dump 文件中可以获取到（ 这仍然取决于 Heap Dump 文件的类型） 如下信息：
 对象信息：类、成员变量、直接量以及引用值；
 类信息： 类加载器、 名称、 超类、 静态成员；
 Garbage Collections Roots： JVM 可达的对象；
 线程栈以及本地变量： 获取快照时的线程栈信息， 以及局部变量的详细信息。
Heap Dump 文件中并不包含内存分配信息， 所以通常无法通过 Heap Dump 文件解决是谁以及在哪里创建了哪些对象这样的问题。

MAT根据这个文件可以分析出内存泄露和高内存消耗的i。

我们可以通过触发一次OOM for Heap来获取Heap Dump文件。

测试代码:

/**
 * 
 * @description HeapOOM
 * <p>Java堆异常测试</p>
 * <code>VM Args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError</code>
 * <p>以上参数的含义是：限制Java堆大小为20MB，不可扩展</p>
 * <p>通过此参数可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照</p>
 * @author YellowStar
 * @date 2018年10月13日
 */
public class HeapOOM {

    static class OOMObject { }

    public static void main(String[] args) {

        List<OOMObject> list = new ArrayList<OOMObject>();
        while (true) {
            list.add(new OOMObject());
        } /// while end
    } /// main
} ///~

/**
 * 运行结果：
 * java.lang.OutOfMemoryError: Java heap space
 * Dumping heap to F:\job\java_pid14444.hprof ...
 * Heap dump file created [28010445 bytes in 0.373 secs]
 * Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 */

Eclipse中的运行参数设置

-Dfile.encoding=UTF-8   
-Xms20m -Xmx20m ##设置堆大小20m，并将最小和最大值设置相等，避免扩展
-XX:+HeapDumpOnOutOfMemoryError ##dump出当前的内存堆转储快照
-XX:HeapDumpPath=F:\job   ##指定路径(转储文件还是挺大的)
-XX:SurvivorRatio=8    ## 存活比2:8

运行生成一个hprof格式的文件

使用MAT工具分析文件

分析三步曲

通常我们都会采用下面的“三步曲”来分析内存泄露问题：

首先，对问题发生时刻的系统内存状态获取一个整体印象。

第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象

接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。

下面将用一个基本的例子来展示如何采用“三步曲”来查看生产的分析报告。

查看报告之一：内存消耗的整体状况

在报告上最醒目的就是一张简洁明了的饼图，从图上我们可以清晰地看到一个可疑对象消耗了系统 97% 的内存。

在图的下方还有对这个可疑对象的进一步描述。我们可以内存是由 java.lang.Object[]的数组实例消耗的，system class loader 负责这个对象的加载。这段描述非常短，但我相信您已经可以从中找到很多线索了，比如是哪个类占用了绝大多数的内存，它属于哪个组件等等。

接下来，我们应该进一步去分析问题，为什么一个 Object[]会占据了系统 99% 的内存，谁阻止了垃圾回收机制对它的回收。

 

查看报告之二：分析问题的所在

首先我们简单回顾下 JAVA 的内存回收机制，内存空间中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的，它的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。

在垃圾回收机制中有一组元素被称为根元素集合，它们是一组被虚拟机直接引用的对象，比如，正在运行的线程对象，系统调用栈里面的对象以及被 system class loader 所加载的那些对象。堆空间中的每个对象都是由一个根元素为起点被层层调用的。因此，一个对象还被某一个存活的根元素所引用，就会被认为是存活对象，不能被回收，进行内存释放。因此，我们可以通过分析一个对象到根元素的引用路径来分析为什么该对象不能被顺利回收。如果说一个对象已经不被任何程序逻辑所需要但是还存在被根元素引用的情况，我们可以说这里存在内存泄露。

现在，让我们开始真正的寻找内存泄露之旅，点击“Details ”链接，可以查看对可疑对象 的详细分析报告。

1. 我们查看下从 GC 根元素到内存消耗聚集点的最短路径：

我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的集合。

接下来，我们再继续看看，这个对象集合里到底存放了什么，为什么会消耗掉如此多的内存。

在这张图上，我们可以清楚的看到，这个对象集合中保存了大量 OOMObject对象的引用，就是它导致的泄露。

然后就可以定位到相应的代码进行优化了。