【原创】一次关于Netty+Gson造成内存泄露 Memory Analysis分析

 http://just2do.iteye.com/admin/blogs/2181293  之前写过一篇使用java自带工具去分析内存泄露问题，今天使用 Memory Analysis重做一次，看看高级工具是否能一针见血地更方便地发现问题。

 

第一步：

 

jmap -dump:format b,file=abc.hprof <pid>

dump出内存日志

 

 第二部：

 

使用Memory Analysis打开abc.hpro

 

 

 

从上图可以看到，泄露内存部分占用了快500M了。而整个应用也就分配了500M。

 

 

 

从直方图可以看到，前五位对象已经占用了快300M的内存。所以我们焦点放在这里，去排查内存泄露点。

 

 

 

 

 

从上图可以看到，9个线程对象很平均地占用了50M左右的内存。那我们随机取一个NIO线程对象出来分析。

 

 

 

从上图可知，一个线程只占用极小内存，但是它却引用了非常大量的其他对象，而且不能释放掉。

 

 

这些对象，最终是被本地线程变量MAP所引用。

 

 

在直方图上，我们 选择第一条，右键“list objects”下选择“with incoming references”

 

 

 

从下图可知，这些对象都是被一些业务数据bean所引用

 

 

 

在直方图上，我们 选择第一条，“Path to GC Roots”->"exclude weak references"

 

从垃圾回收路径看到，本地线程变量所保存的数据，最终还是由gson类所引用业务数据。

到这里，我们就可以针对所有使用gson的地方进行排查了。

 

 

总结：通过两种不同方法对同一个内存泄露现象进行分析，我们可以看到，其实使用java自带工具进行分析，完全能够快速定位问题所在，因为特征信息很明显。特别是对系统比较熟悉的情况下，完全可以出奇制胜，一步到位。使用MAT，我们可以更直观和看到更丰富的信息。甚至丰富到影响你的排查。：）

 

在当前这个案例来看，MAT并不能体现出多大的优势。但如果泄露特征信息不明显的情况下，MAT还是具有很强大的树状内存追踪能力的。

 

内存泄露分析，难点在于没有统一、固定的分析解决方法，全靠的是经验、分析能力、对系统的熟悉和感觉！