内存泄露的解决方法

分析内存泄露的一般步骤

1. 把Java应用程序使用的heap dump下来
2. 使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象
3. 必要时，需要分析嫌疑对象和其他对象的引用关系。
4. 查看程序的源代码，找出嫌疑对象数量过多的原因。

一、dump文件获取

jmap -dump:format=b,file=文件名 [pid]
           

二、下载Java heap分析工具，这里使用Memory Analyse Tool，用免费的没错

下载地址是：http://www.eclipse.org/mat/downloads.php

在MemoryAnalyzer.ini文件，修改MAT可用内存，需要dump文件大。调整-Xmx属性，默认是1024M，我给改成了3024M。

三、加载dump文件

点击File–>Open Heap Dump，选择dump文件，MAT会加载并分析该dump文件，如果文件较大，可能需要一些时间。

开始分析时可以选择是否分析可能存在的问题，如果选择是，MAT会提供Problem Suspect，这个Problem Suspect如果你切到别的标签再切回来就没有了，可以通过点击Leak Suspects链接重新获得。Problem Suspect1和Problem Suspect2表示两个可疑对象，Remainder表示其它对象。

四、分析dump文件结果

1.向下拉动界面，展示了一些分析结果，表示3728个Configuration对象被HashMap引用。

3,728 instances of "org.apache.hadoop.conf.Configuration", loaded by "org.apache.catalina.loader.ParallelWebappClassLoader @ 0x6c00717c0" occupy 411,961,384 (31.76%) bytes. These instances are referenced from one instance of "java.util.HashMap$Node[]", loaded by "<system class loader>"

Keywords
org.apache.hadoop.conf.Configuration
org.apache.catalina.loader.ParallelWebappClassLoader @ 0x6c00717c0
java.util.HashMap$Node[]
           

2.再点击下面的类引用图，点击HashMap对象，查看左上角该对象的一些概要信息。发现key是FileSystem C a c h e Cache CacheKey，value是DistributedFileSystem

3.查到这里我们就可以分析自己的代码，为什么引用了这么多对象。如果引用里面直接定位到问题行，事情就好办了。但我这里的案例没法直接定位到工程问题行，DistributedFileSystem是hadoop HDFS的类。我就google搜索了hdfs FileSystem内存泄露，果然有类似的问题。最后定位发现是有些代码fs没有关闭，导致fs缓存不断累积，最后导致内存溢出。也算填了前人的坑。总之要善用搜索引擎，如果搜索不到，也只能一步步分析调试源码了。