那么问题来了：内存泄露排查工具到底哪家强？

Question

现在我想排查一下服务器上tomcat总是宕机的原因，从log中看出来的是“堆溢出”错误，我想问问大家，排查内存泄露的常用工具有哪些？那个用的最趁手？

网上搜了搜，只看到2个出彩的：
1.JRockit
2.JProfiler
大家又推荐哪个呢？？

PS：最后我选择了jprofiler，因为jrockit需要jrockit vm，而我们的环境使用的是hotsopt~~

Answer 1

推荐使用plumbr。
Plumbr是一款监控JVM的工具，能检测的内存泄露，GC时间过长，线程锁的情况。最近公司小伙伴自己业余时间开发的运营系统时不时崩溃，处于玩耍新工具的心态，我们使用了Plumbr来作为我们的JVM性能监控工具。
首先你要在他们的网站注册一个新账号，将它的jar包下载下来。然后根据JVM的不同大概会有一些区别，以TOMCAT来说，就是在bin目录里的catalina.sh中多加入JAVA_OPT。

-javaagent:/path-to/plumbr.jar

然后再重启的时候将这个jar包带起来，从而实现对数据的抓取。

---

PLUMBR的支持范围：
JDK Version
Oracle HotSpot 6, 7 and 8
Open JDK 6 and 7 28
Application Server Version
Jetty 7+
Apache Tomcat 6+
JBoss Application Server 7+
Oracle WebLogic Server 8+
RedHat WildFly 8+
Glass-fish 4+

---

基本上包括了主流的jvm系统，还是支持的蛮全的。支持的语言当然只有JAVA，不过在它官网是这么说的：
Although officially Plumbr supports only Java, we encourage all users of other JVM-based languages – such as Groovy, Jython, JRuby, Clojure, Scala etc – to give it a try and let us know about the test results. This will help us further broaden the list of supported environments.

反正他也不知道能不能支持，你可以试试看~~

---

它抓取的信息包括以下内容：

对于操作系统，JVM设置和启动参数，通过RuntimeMXBean和System.getProperties接口获得的数据。
关于garbage collection events的信息 - gc的频率，收集时间，释放内存等量
有关对象分配的统计信息。信息是基于分配点进行收集的，包括类名和根据类名创建的对象和创建对象的代码行。
事件报告的数据。内存泄漏，事故报告包含对象计数，占用的空间，分配点（包括类名称和代码行）和线程的堆栈跟踪。

总结来说就是，JVM的设置，GC的log，和基于堆栈信息拉出来的对象信息。

---

成功部署以后，进入的页面非常的简洁：
首先关注的是堆内存的使用情况，是否有泄漏，泄露的话会通过leaksize绘出红色的泄露情况。

从图表上可以看出我现在的内存还是没有泄露的。图表右上角有一个threshold，可以设置阀值，一旦发现有泄漏的情况就给你发报警邮件。

第二个图表是GC回收时间，从这里可以看到你每次GC的回收时间是多少，还是通过右上角的设置自定义你觉得多长时间是长GC，这里由于我设置的事1MS，所以几乎每次GC都被当做成了长GC.
第三个图表示是对线程锁的监控，从这里可以看出这一小时内你的锁的数量和时间，是否存在超长时间的锁。

---

对于上述图表出现的问题，plumbr会详细记录每一次问题的情况，以便用户查找。

对于每一个问题，它还有详细的描述，包括问题发生的机器，时间，造成问题的原因，问题发生的对象和方法等等，甚至有一些常见的问题，它还能告诉你怎样修复它。这可以说是它最吸引我的地方。
附上一个它对我memory leak诊断的链接：
https://portal.plumbr.eu/shared#/incident/188484?token=wgy4UKRNk13Wvt7-ZWzy1cH__Eg
不只是memory leak，对长GC和锁它好像也要有所诊断，不过因为不是付费版所以不太清楚。

Answer 2

1. jmap -dump:live,format=b,file=heap.bin <pid>
2. eclipse mat 打开 heap.bin ,一目了然

当然建议你先用jmap -histo:live <pid> |less 先看看,也许直接能找到答案