HPROF –内存泄漏分析教程

本文将为您提供有关如何通过生成和分析Sun HotSpot JVM HPROF堆转储文件来分析JVM内存泄漏问题的教程。

一个现实的案例研究将用于此目的：Weblogic 9.2内存泄漏影响Weblogic Admin服务器。

环境规格

Java EE服务器：Oracle Weblogic Server 9.2 MP1
中间件操作系统：Solaris 10
Java虚拟机：Sun HotSpot 1.5.0_22
平台类型：中间层

监控和故障排除工具

Quest Foglight（JVM和垃圾收集监视）
jmap（hprof /堆转储生成工具）
通过IBM支持助手进行的Memory Analyzer 1.1（hprof堆转储分析）
平台类型：中间层

步骤＃1 – WLS 9.2管理服务器JVM监视和泄漏确认

Quest Foglight Java EE监视工具对于从Weblogic Admin服务器识别Java堆泄漏非常有用。如下所示，Java Heap内存随着时间的推移而增长。

如果您没有为Weblogic环境使用任何监视工具，那么我建议您至少启用HotSpot VM的verbose：gc。请访问有关此主题的Java 7 verbose：gc教程，以获取更多详细说明。

步骤＃2 –从泄漏的JVM生成堆转储

发现JVM内存泄漏后，目标是使用Sun JDK jmap实用程序生成堆转储文件（二进制格式）。

**请注意，生成jmap堆转储将导致您的JVM无法响应，因此请确保在运行jmap实用程序之前，没有更多的流量发送到受影响的/泄漏的JVM **

<JDK HOME>/bin/jmap -heap:format=b <Java VM PID>

此命令将生成泄漏的JVM的堆转储二进制文件（heap.bin）。文件的大小和生成过程所花费的时间将取决于您的JVM大小和计算机规格/速度。

对于我们的案例研究，在大约1小时的时间里生成了约2 GB的二进制堆转储文件。

由于OutOfMemoryError并在JVM启动参数中添加-XX：+ HeapDumpOnOutOfMemoryError，也会自动生成Sun HotSpot 1.5 / 1.6 / 1.7堆转储文件。

步骤＃3 –在Memory Analyzer工具中加载堆转储文件

现在是时候在Memory Analyzer工具中加载堆转储文件了。加载过程将需要几分钟，具体取决于堆转储的大小和计算机的速度。

步骤＃4 –分析您的堆转储

内存分析器为您提供了许多功能，包括“可疑泄漏”报告。对于此案例研究，以Java堆直方图为起点来分析泄漏的对象和源。

对于我们的案例研究，发现java.lang.String和char []数据是泄漏的对象。现在的问题是泄漏的根源是什么，例如那些泄漏对象的引用。只需右键单击泄漏的对象，然后选择>>列出对象>带有传入引用的引用

如您所见，发现javax.management.ObjectName对象是泄漏的String＆char []数据的源。 Weblogic Admin服务器正在通过MBeans / JMX通信并从其受管服务器中提取统计信息，该MBeans / JMX为任何MBean对象类型创建javax.management.ObjectName。现在的问题是，为什么Weblogic 9.2无法正确发布此类对象……

根本原因：Weblogic javax.management.ObjectName泄漏！

在我们进行堆转储分析之后，对Weblogic的已知问题进行了回顾，但确实发现了以下Weblogic 9.2错误：