内存泄漏排查

问题定位

大量报错报警，查看日志，发现如下堆栈：

java.io.BufferedReader.readLine(BufferedReader.java:371)
java.io.BufferedReader.readLine(BufferReader.java:389)
java_io_BufferedReader$readLine.call(Unknown Source)
com.domain.detect.http.HttpClient.getResponse(HttpClient.groovy:122)
com.domain.detect.http.HttpClient.this$2$getResponse(HttpClient.groovy)

没有头绪，于是在一次报警时，快速登录服务器，使用top、free、df三板斧，结果发现了些异常：

image.png

发现CPU占用率特别高，知道这个时间点并没有做大量CPU运算，于是怀疑是死循环，或大量GC导致的。
于是使用 jstat -gc pid [interval] 查看java进程的gc状态, 发现Full GC频率很高

image.png

于是想到可能是内存泄漏了。
使用jstack pid > jstack.log 保存线程栈的现场。
使用```jmap -dump:format=file,file=heap.log pid 保存堆现场

然后重启服务，报警停止

排查

为了防止问题再次发生，需要定位到根源

分析栈

栈的分析很简单，看下线程数是不是过多，多数栈都在干什么

> grep 'java.lang.Thread.State' jstack.log  | wc -l
> 464

发现只有400多线程，并无异常

> grep -A 1 'java.lang.Thread.State' jstack.log  | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n

     10  at java.lang.Class.forName0(Native Method)
     10  at java.lang.Object.wait(Native Method)
     16  at java.lang.ClassLoader.loadClass(ClassLoader.java:404)
     44  at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
    344  at sun.misc.Unsafe.park(Native Method)

线程状态也无异常

分析堆文件

下载dump文件到本地(可以先压缩)，使用mat工具分析
MAT 是分析 Java 堆内存的利器，使用它打开我们的堆文件（将文件后缀改为 .hprof）, 它会提示我们要分析的种类，对于这次分析，果断选择 memory leak suspect。

image.png

从上面的饼图中可以看出，绝大多数堆内存都被同一个内存占用了，再查看堆内存详情，向上层追溯，很快就发现了罪魁祸首。

image.png

分析代码

找到内存泄漏的对象了，在项目里全局搜索对象名，它是一个 Bean 对象，然后定位到它的一个类型为 Map 的属性。
这个 Map 根据类型用 ArrayList 存储了每次探测接口响应的结果，每次探测完都塞到 ArrayList 里去分析，由于 Bean 对象不会被回收，这个属性又没有清除逻辑，所以在服务十来天没有上线重启的情况下，这个 Map 越来越大，直至将内存占满。
内存满了之后，无法再给 HTTP 响应结果分配内存了，所以一直卡在 readLine 那。而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。