JRockit Memory Leak Detection工具（下面简称Memleak）是JRockit Mission Control 2.0（JRockit工具套件）的一部分。它在查找Java中的内存泄漏方面为相当多的人提供了服务，也就是查找为什么没有使用的对象仍然存在引用的原因。

　　关于如何使用Memleak查找这些内存泄漏已经有充分的讨论，因此这个blog文章将向您展示该工具的其他有趣用途。

　　首先我们将研究Memleak如何帮助我们查看JVM中是否正在使用任何指定的类型。

　　启动Mission Control，将其固定在JRockit中，然后什么也不作只是睡眠。在我的案例中，将其连接到网络上的JRockit，它是使用JRockit Discovery Protocol发现的。

　　您可能希望通过按下趋势表上方工具栏中的暂停按钮来暂停该表的更新，尤其是在JRockit非常忙碌的时候。

　　暂停更新该表之后，找到希望研究依赖项的类，比如说Hashtable条目(java.util.Hashtable$Entry)，然后从上下文菜单中选择Show Referring Types，了解哪些内容指向这个特定类型。

　　您将毫不惊讶地发现hashtable条目数组指向这些条目。单击加号进一步深入，就会毫不惊讶地发现各种hashtable副本指向这些数组。单击Hashtable以查找谁正在使用Hashtable。哇！？我们发现箭头有趣地从我们的条目指向Hashtable，这样我们就在图中获得了一个基本了解。

　　很明显，有些人将Hashtable放到了Hashtable中。那么，是谁这么做呢？观察一下参与形成这个特定关系的实例。打开java.util.Hashtable$Entry的上下文菜单，然后选择显示实例。将弹出一个对话框，提示您选择希望列出的实例关系。我选择Hashtable，因为我希望找出哪些条目指向hashtable。然后获得了一列条目，在我的案例中为5个候选条目。

　　可以看出，其中4个使用了100 000字节的数据。选择最多的一个 - 打开上下文菜单，然后选择显示指向该特殊实例的条目（Show Referring Instances）。

　　进一步研究，可以看到com.sun.jmx.mbeanserver.RepositorySupport拥有包含Hastable的Hastable。现在我们可以选择RepostiorySupport实例，并打开上下文菜单然后选择“Inspect Instance”，以验证它是否确实拥有该Hastable。

总结：

　　在这个示例中，我们使用Mission Control中的Memory Leak Detector查看正在运行的JVM中各种类型和实例之间的关系。在这个特殊的案例中，我们查找了人们在何处将hashtable放到hashtable中。

原文出处：http://dev2dev.bea.com/blog/hirt/archive/2007/03/unorthodox_uses.html