小哥最近在分析项目中的内存泄露情况，使用了Eclipse Memory Analyzer，移步到这里下载最新版本：
我们知道，不同版本的虚拟机和JDK版本，垃圾回收机制和内存空间布局都是有所差别的，我使用的是这个版本的JDK
java version “1.6.0_26”
Java™ SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot™ Client VM (build 20.1-b02, mixed mode, sharing)
1、下面监控一下我开发环境下的Resin服务器：
首先，运行JDK bin目录下的jconsole.exe文件，链接到Resin服务器：
进入之后，就可以查看到堆内存，类，CPU的使用情况了。
细心的读者发现了我使用的是主流的HotSpot虚拟机。选择 com.sun.management–>HotSpotDiagnostic–>操作–>dumpHeap(堆转储)，在操作调用中的p0填写导出目录，点击dumpHeap即可：
这样就可以在p0对应的输出目录中找打导出的文件了：dumpHeap.hprof
接下来启动MemoryAnalyzer, File --> Open File… 选择刚才导出的文件进行分析。
选择目录中的Path To GC Roots --> exclude weak/soft references 排除掉弱引用，剩下的才是最有可能导致内存泄露的问题：
目前查看到的都是classloader加载到的Class文件的引用，并没有发现异常信息：
继续观察，发现问题随时分析。
哦对了，ClassLoader也是有可能产能内存泄露的哦，详细请查看我的这篇文章：
How to creating a memory leak with Java
2、监控一段测试程序：
可以通过配置Java的 -XX:+HeapDumpOnOutOfMemoryError 参数让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照。
下面是来自深入理解Java虚拟机的例子：
/**
- VM Args:-verbose:gc -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
- 限制Java堆大小为20M，不可扩展，让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照
- @Author zzm
*/
public class HeapOOM{
static class OOMObject{
}
public static void main(String[] args){
Listlist = new ArrayList ();
while(true){
list.add(new OOMObject());
}
}
}
执行后可以发现转储快照被导出了：
Dumping heap to java_pid4148.hprof …
Heap dump file created [24728647 bytes in 0.342 secs]
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.util.Arrays.copyOf(Unknown Source)
at java.util.ArrayList.ensureCapacity(Unknown Source)
at java.util.ArrayList.add(Unknown Source)
at me.arthinking.memoryleaktest.HeapOOM.main(HeapOOM.java:18)
接下来使用MemoryAnalyzer分析这个文件就可以了。
如果是内存泄露，可以进一步通过查看泄露对象到GC Roots的引用链。
如果不存在内存泄露，就应当坚持虚拟机的堆参数（-Xmx和-Xms）。
