记一次线上内存泄漏问题的排查过程最新消息

近期需要对公司的界面做线上的巡查监控，需要写一个指令码放到服务器上，定时执行指令码监测线上界面是否正常。

测试的界面不是HTTP协议，而是公司基于TCP协议开发的私有协议，因此不能直接用现成的一些界面测试工具，需要自己写程式码来呼叫界面。

由于是私有协议，为了方便各业务专案进行通讯，开发部门统一提供了一个TClient的jar包，底层使用了netty框架进行通讯。呼叫方只需要按照协议的格式组装二进位制的包，然后直接呼叫TClient的sendMessage方法就可以把资料传送出去，服务端处理完成后会异步回拨，将响应资料返回给客户端。

指令码写完了，虚拟码如下

public class Demo{

public void invoke(){

// 建立TClient并初始化

TClient client = new TClient(xxx);

// 组装界面资料包

Data data = new Data(xxx);

// 传送资料

Response res = client.sendMessage(data);

// 检查结果、储存结果、传送邮件

doSomething();

// 关闭client

client.close();

}

测试指令码中，每隔一分钟，建立一个Demo物件，呼叫invoke方法

Demo demo = new Demo();

demo.invoke();

指令码写好后在服务器上除错了下，界面返回资料正常，于是正式启动定时任务，观察了一会，执行一切正常，Perfect！

第二天早上到公司，登上服务器，检视昨晚指令码的执行情况，看了下日志。

开启日志我就震惊了，What？OutOfMemoryError！竟然内存泄漏了！

平常都是开发写bug时出现内存泄漏，今天终于轮到我自己了！

最后一条日志显示为下午17:17左右，也就是指令码大概运行了4小时后出现了内存泄漏。查看了下指令码程序，果然已经崩溃了，并且生成了一个dump档案。

经常做效能测试的同学，对内存泄漏都不陌生。内存泄漏总结来说就是JVM中储存的物件太多了，占满了全部内存空间，并且这些物件都是不可回收的。这样程式就不能再继续运行了，因为已经没有空间了。

举个例子，就好像去饭馆吃饭，饭馆里总是不断的有人进去，也有人出来。如果某天来了一帮人占满了饭店，并且赖著不走了，这样新顾客就进不来了，这个时候估计老板就崩溃了。

我先review了指令码的程式码，没发现什么异常的问题。有的朋友可能会说，你不是每个1分钟建立一个Demo物件吗，执行这么长时间，会不会是Demo物件太多了？

其实并不会，写指令码的时候也考虑过这个问题，每次new Demo物件，因为上一次指令码已经执行完了，那么上一次的Demo物件就没有引用了，这样JVM在垃圾回收的时候会把上一次的Demo物件清理掉。这样并不会造成内存泄漏。

目光再回到服务器上，Java程序在崩溃时，自动生成了一个堆dump档案，如果已经发生了内存泄漏，可以分析这个dump档案，看看里面那些物件比较多，这样就能确定原因了。

一般在工作中分析内存泄漏时，可以把dump档案下载到本地，然后通过jvisualvm或者jprofiler开启档案，工具自动会分析哪些物件数量最多。

但是这个档案有1.3G，公司服务器下载有限速，想下载下来估计得等到7月7号testfan效能测试实战班开课那天了。

突然想到另外一个分析内存泄漏的工具MAT，之前都是在windows下使用MAT，其实MAT也有Linux版本，可以直接在服务器上对dump档案进行分析。

简单介绍下工具的使用方法：

1、登入官网，下载Linux x86_64/GTK+版本

https://www.eclipse.org/mat/downloads.php

2、解压后修改MemoryAnalyzer.ini配置档案，配置jvm引数（要比dump档案大）

3、执行.mat提供的指令码

./ParseHeapDump.sh /home/xxx.hprof org.eclipse.mat.api:suspects

（/home/xxx.hprof是dump档案的路径）

4、在xxx.hprof目录下，生成了java_pid32523_Leak_Suspects.zip压缩档案

5、下载到windows下，解压，开启index.html

在分析页面中可以看到，io.netty.channel.nio.NioEventLoopGroup物件占用了JVM中61.36%的空间。其次是io.netty.buffer.PoolThreadCache物件，占用了21.38%。

看名字这俩物件都是netty框架中的类，在网上查了下资料，“NioEventLoopGroup”是netty中的一个执行绪池物件。

看页面上的统计，JVM中有1145个netty的执行绪池物件，这是什么操作？执行绪池不就一个就行了吗？为什么有这么多？

看到执行绪池物件，就想到会不会JVM执行绪方面有问题？因为指令码程序现在已经崩溃了，只能重新执行指令码，然后再对执行绪进行监控。

指令码执行过程中，通过监控jvm，发现old区确实在不断的缓慢增加，这样长时间跑下去，应该就会重现昨天晚上的问题。

执行jstack命令打印执行绪堆叠资讯

jstack pid > thread.log

开启thread.log看了下，执行绪状态倒没啥问题，但是堆叠中有大量的nioEventLoopGroup执行绪，看编号有1000+，通过命令统计了下，确实有1000+个nioEventLoopGroup执行绪。

这个数量跟上面MAT工具分析的例项数量也差不多对应上了，现在问题基本上就确定了。也就是说在内存泄漏发生前，JVM中存在1000+个nioEventLoopGroup执行绪，每个执行绪建立了一个NioEventLoopGroup物件，因为执行绪池的特性，所以这些执行绪处于都是执行状态的。

并且在指令码执行过程中发现，这个nioEventLoopGroup执行绪并不是开始就是1000+，而是从0慢慢涨上来的。也就是说随着指令码的执行，慢慢积累上来的。

这个时候目光又回到了我的指令码中，虽然并不是因为我不断的new Demo物件造成了内存泄漏，但是肯定跟这个行为有关系，nioEventLoopGroup是netty框架用到的物件，于是就想到了程式码中的TClient client = new TClient(xxx);

开启TClient的jar包看了下，在TClient的建构函式里，确实建立了一个nioEventLoopGroup物件

然后在connect方法中，使用了这个执行绪池物件bossGroup

现在基本上确定是什么原因了，如下：

a> 每隔1分钟，指令码会new一个Demo物件

b> Demo物件的invoke方法里又new了一个TClient物件

c> TClient物件内部在做netty连线初始化的时候，建立了NioEventLoopGroup执行绪池物件

虽然指令码中建立的Demo物件和TClient物件都会被JVM回收，但是可能是因为netty使用NioEventLoopGroup执行绪池和服务端建立了长连线，导致执行绪池物件并不会被回收。这样长时间跑下来，JVM中中的NioEventLoopGroup物件就会越来越多，最终导致了内存泄漏。

这么来看，还真是每次new Demo间接带来的影响。知道原因就好说了，Demo物件不能在每次执行的时候建立，而且放在类初始化的时候建立一个。无论指令码跑多少次，都只有一个NioEventLoopGroup物件了。

重新修改了下指令码，长时间执行监控了下，确实内存使用很稳定，没有出现内存泄漏的情况。

问题似乎是得到了解决，但是等等。我脑海中突然又想到另外一个问题，虽然我在指令码中每次都建立一个TClient物件，但是每次跑完后，都会呼叫TClient的close方法啊，close方法里应该会释放NioEventLoopGroup物件啊，难道没做吗？

开启TClient的jar包看了下close方法

在close方法中，确实把NioEventLoopGroup置为null了，对于一个普通的物件来说，只要物件引用为null，那么在下次JVM垃圾回收的时候，就会把这个物件回收掉。但是对于一个执行绪池物件来说，因为执行绪池中有活动执行绪存在，所以尽管置为null了，JVM也不会回收这个执行绪池。一般的执行绪池物件，都是通过shutdown方法来销毁执行绪池的。

查看了下netty的api文件，确实有shutdownGracefully方法（优雅关闭）