分析垃圾堆是解决内存外问题最普遍的方法，也是唯一可靠的方法。在这篇文章中，我将使用Eclipse MAT，因为这是我最有经验的工具，但是您可以对任何其他类似的工具采取类似的方法。
在我们开始之前，请注意，有些作者使用术语“堆转储”来描述内存转储。在Java世界中，堆转储和内存转储的意思是一样的。在这篇文章中，我将两者互换使用。
什么是 Memory Dump“内存转储”？
内存转储是Java虚拟机内存的快照，在特定时刻拍摄。通常保存在磁盘上以备进一步分析。
使用转储，JVM内存内容可以在开发人员闲暇时使用各种工具，在远离敏感生产站点的开发人员舒适的环境中进行调查。调查的最终目标是找到消耗过多内存的对象以及这些对象在运行的应用程序中的位置。
你知道20%的Java应用程序有内存泄漏吗？不要杀死你的应用程序-而是在几分钟内找到并修复漏洞。
如何创建内存转储Dump文件？
内存转储可以通过两种方式创建：
1. 通过将“-XX:+HeapDumpOnOutOfMemoryError”添加到java start命令中，如下所示：
java-XX:+HeapDumpOnOutOfMemoryError-Xmx512m…当您像这样启动您的JVM时，每当JVM抛出第一个OutOfMemoryError（OOM），就会将完整的内存转储写入磁盘。尽管在开始寻找问题的原因之前等待JVM崩溃可能有点苛刻，但我强烈建议在没有这个参数的情况下，任何JVM都不能在生产环境中运行。让我再强调一次：现在就把这个参数添加到生产服务器配置中！原因很简单：如果您的生产服务器遇到OutOfMemoryError，那么您将希望拥有该内存转储。这将是事后分析中最有用的数据，通常仅垃圾堆就足以找出坠机原因。
2. 创建正在运行的应用程序的内存转储。这可以通过使用VisualVM、eclipse mat或我们在上一篇博客文章中描述的jmap命令行工具来实现。但在我们到达目的地之前，让我指出一件非常重要的事：你应该明智地选择你倾倒垃圾的时间点。您的目标是解决困扰应用程序的内存不足问题。正如我在另一篇文章中所解释的，为了找到内存泄漏的原因，必须让它自己显现出来。在应用程序启动2秒后尝试查找内存泄漏是没有意义的（除非在启动后5秒它崩溃了）。让用户使用应用程序，让它消耗足够的内存，让垃圾回收器尝试释放内存。我建议你至少用50%的内存来收集垃圾。
使用Eclipse MAT工具获取内存转储dump文件如下所示：
我在这里应该注意到，内存转储通常意味着“冻结”应用程序内存，这与完全垃圾回收类似。因此，您的应用程序在此期间不会响应用户的请求。要多长时间？比在服务器硬盘上写入与应用程序的堆相对应的原始数据要多一些。在某些情况下，可能需要几分钟。
内存转储分析
好了，现在内存转储完成了，并从生产站点转移到开发人员的机器上。当您用MAT打开它时，您会看到以下图片（经过一段漫长的过程来解析这个千兆字节的文件）：
在后台，您可以看到堆转储的可视化表示，其中突出显示了最胖的对象。我们很快就会知道的。在前台，MAT工具提出了一些“入门”选项。暂时让我们选择第一个，Leak Suspects Report“泄密嫌疑报告”。经过一些分析后，将显示以下内容：
如您所见，MAT发现了一个泄漏嫌疑，它占应用程序内存的89%，由类的实例获取org.springframework.samples.petclinic.web.LeakingInterceptor. 如果你点击Details“细节”链接，你会看到更多关于实例所在位置以及它们为什么这么大的信息。
现在让我们回到你打开dump分析的MAT视图上:
当您点击最大的片段时，您可以选择“Paths to GC Roots”或“Merge Shortest Paths to GC Roots”，以便找到容纳大量实例的内容。或者单击“List objects with outgoing references 列出具有传出引用的对象”以查看其中已累积的内容。根据我的经验，上面的信息是所有你需要去你的源代码，并开始考虑修复错误。
然而，在最后一点上，我想指出的是，内存转储不是银弹。与他们一起工作也有一些缺点。
- 从实时应用程序中获取它们会使客户端在一段时间内无响应。如果不考虑崩溃应用程序的成本，从崩溃的应用程序中获取它们是免费的。
- 分析千兆字节的内存转储至少需要开发人员计算机的内存。32GB以上的服务器现在比32GB的开发人员工作站更常见。
- 如果在错误的时间执行内存转储，则它包含大量的噪声。你可能会浪费很多时间在大海捞针（在某些情况下，可能需要获得一个额外的草堆）。
原文链接：http://javakk.com/1044.html
如果觉得本文对你有帮助，可以转发关注支持一下