inputstreamreader未关闭会导致oom_java之OOM排查

1.引子

今天聊一下OOM的问题。OOM就是Out Of Memory。前几天，线上出现过一次，频繁的full GC的问题。今天就简单记录一下排查的步骤。

2.模拟

在这只能模拟OOM。很简单，就是一个集合，写个循环向里面添加对象。这个方法：startThread2

import java.util.ArrayList;import java.util.List;class Test {    public static void main(String[] args) {        if (args.length == 0) {            System.out.println("运行的时候请输入参：1 or 2");            return;        }        if (args[0].equalsIgnoreCase("1")) {            startThread1();        }        if (args[0].equalsIgnoreCase("2")) {            startThread2();        }    }    public static void startThread1() {        Thread thread = new Thread(new Runnable() {            @Override            public void run() {                while (true) {                    String a = new String("deadThread");//System.out.println(a);                }            }        });        thread.setName("deadThread");        thread.start();    }    public static void startThread2() {        Thread thread = new Thread(new Runnable() {            @Override            public void run() {                List list = new ArrayList<>();                while (true) {                    String a1 = new String("OOMThread");                    list.add(a1);                }            }        });        thread.setName("OOMThread");        thread.start();    }}

3.编译运行

javac test.java

javac test.java

java -Xms10m -Xmx10m -XX:+PrintGC -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ Test 2

注:

-Xms10m -Xmx10m 初始堆大小和最大堆大小。 这里是模拟，所以设置小一点

-XX:+PrintGC -XX:+PrintGCDetails 打印一下GC的日志

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ 当发送OOM的时候，自动保存Dump文件。后面那个是报错的路径，如果没有则，在当前目录下。

已运行会一直打gc日志，因为死循环在添加对象，并且对象还没法回收。

一会就会内存溢出，如下图

4分析dump文件

发生OOM了。接着就是要分析一下这个dump文件了。分析的工具有很多，这里使用mat和jvisualvm分别分析一下，其实都差不多。

首先，从服务器下载到本地。然后使用工具就行分析。

1.首先使用MAT分析：

打开mat，导入hprof文件。(注：如果hprof文件特别的大，需要调整一下mat的内存参数。防止内存溢出，打不开文件)

mat

我们可以看到mat已经帮我们分析到了一个错误：

点击details详情。会发现：

线程 OOMThread中一个ArrayList占了98.12%，而它里面放的是String对象。

注：这里面有两个比较难理解的名词(我理解的不一定完全对。大家可以自行百度一下)：

1.shallow heap：shallow：浅的，我理解就是:这个对象实际占用的堆大小

2.retained heap：retained：保留的,这个有点难理解了：简单的话，就是它和它引用的对象(这里的引用对象没有被其他的对象引用)的占用堆的大小。(不知道理解的对不对。)如下图：arrayList中shallow是24，retained是9057600.以为我newString的都放到list中去了。

初步怀疑是ArrayList中对象过多，一直有引用，没有被gc回收导致。然后看一下抛出OOM的异常的地方。发现有对应的ArrayList。它有一个循环在一直添加String对象。

2.使用jvisualvm.exe

打开jvisualvm.exe，导入hprof文件。

在出现 OutOfMemoryError 异常错误时进行了堆转储导致 OutOfMemoryError 异常错误的线程: OOMThread

点击：OOMThread

显示是在什么地方发生的OOM，然后点击 红框的地方。

我们可以发现：arrayList的size大小为：317374. 猜测是arrayList结合中对象太多。由此可以去查对应的代码逻辑判断。

还可以点击类：会显示对象的个数和占比。会发现string对象，有318309个实例，占所有实例中99.1%，大小是8912652，占用了堆74.2%的空间

注：实际生产中情况，比这个要复杂，不过大概分析过程就是这样。其实频繁的fullgc也可以导出dump文件去分析。是不是有内存泄漏的地方。当然，一般大公司会有相应的监控系统，在堆空间超过某个阈值就会报警，这个时候，可以将这台机器从vip摘除或者(healthcheck先摘除了)这样Nginx就打不过来，就不会有用户的请求过来了。然后使用jmap导出dump文件分析。这个以后有时间再讲。