原文是免费电子书，链接：http://www.javacodegeeks.com/whitepaper/jvm-troubleshooting-guide
以下为本人翻译，仅用于交流学习，版权归原作者所有，转载注明出处，请不要用于商业用途 。
HPROF：使用Eclipse Memory Analyzer 工具 (MAT)进行内存泄露分析
在这个部分，我们将会给你演示如何通过产生一个HotSpot JVM HPROF 堆转储文件来分析一个JVM内存泄露问题。
我们会用一个真实存在的案例来作为研究目的：一个Weblogic 9.2内存泄露，它对Weblogic Admin服务器产生了影响。
环境参数
• Java EE server: Oracle Weblogic Server 9.2 MP1
• 中间件操作系统 : Solaris 10
• Java 虚拟机: Sun HotSpot 1.5.0_22
• 平台类型 : Middle tier
监控工具和诊断工具
• Quest Foglight (JVM 和 垃圾回收监控)
• jmap (hprof / Heap Dump generation tool)
• Memory Analyzer 1.1 via IBM support assistant (hprof Heap Dump analysis)
• Platform type: Middle tier
Step #1 - WLS 9.2 Admin 服务器的JVM 监控和泄露的确认
Quest Foglight Java EE监控工具对于在Weblogic Admin服务器上鉴定Java堆内存泄露是非常有用的。下面你看可以看到，Java堆内存占用随着时间推移增长越来越多。
如果你不使用任何一个监控工具来监控Weblogic环境，我给你的建议是至少在JVM加上verbose:gc。可以参考后面提到的Java 7 verbose:gc 文档来获取更多用法。
Step #2 – 在你泄露的JVM上产生一个堆转储文件
发现了JVM内存泄露问题后，接下来的目标是使用Sun JDK的jmap实用工具产生一个堆转储文件(二进制)
* 请注意一点，使用jmap来生成堆转储会导致你的JVM无响应，所以在使用这个命令前请确保没有更多的业务请求发送到你受影响的/泄露的JVM *
<JDK HOME>/bin/jmap -heap:format=b <Java VM PID>这个命令会生成一个JVM堆转储二进制文件(heap.bin)。这个文件的大小和生成过程所需要的时间取决于你的JVM大小和机器的参数指标/速度。
对于我们这个样例研究而言，2GB的堆转储文件大概需要1个小时的时间生成。
Sun HotSpot 1.5/1.6/1.7堆转储文件也可以在发生OutOfMemoryError时自动生成，只要在JVM启动参数里加上-XX:+HeapDumpOnOutOfMemoryError。
Step #3 – 加载你的堆转储文件到内存分析工具里
现在到了加载你的堆转储文件到内存分析工具的时候了。加载过程可能会花费几分钟，它取决于你的文件大小和机器性能。
Step #4 – 分析你的堆转储文件
这个Memory Analyzer工具会提供给你很多特性，包括泄露检测报告。对于这个案例而言，我们将以Java堆柱状图作为分析泄露对象和源的开始。
对于这个案例，找到的泄露对象是java.lang.String和char[]数据。现在的问题是，泄露的源头在哪，比如泄露对象的引用在哪。右键点击泄露的对象，并选择“List Objects”可以看到很多引用。
* 问题根源 ：Weblogic javax.management.ObjectName 泄露! *
通过我们的堆转储分析可以看到Weblogic已知的一些问题，它说明了如下的Weblogic 9.2 bug：
• Weblogic Bug ID: CR327368
• Description: Memory leak of javax.management.ObjectName objects on the Administration Server used to cause OutOfMemory error on the Administration Server.
• Affected Weblogic version(s): WLS 9.2
• Fixed in: WLS 10 MP1
这个发现和我们的堆转储分析，WLS版本以及已知的问题描述非常符合。
我们希望这份带有样例研究的教程能帮助你了解如何通过使用jmap和内存分析工具去查明Java堆内存泄露的源头。