内存泄漏嫌疑人答案

【问题标题】：Memory Leak Suspects内存泄漏嫌疑人
【发布时间】：2017-06-25 10:19:04
【问题描述】：

在我们的团队中，我们使用的服务存在溢出问题。它是由较长的 API 延迟引起的，其中 GC 时间占用了大部分时间。然后我发现堆内存使用率很高。我使用 jmap 获得了大约 4.4 GB 的服务的堆转储。我使用 Eclipse Memory Analyzer 来解析堆转储。我发现 2.8GB 的堆转储是无法访问的对象。任何人都有建议我应该怎么做才能进一步调试这个问题？谢谢你。

【问题讨论】：

你有没有试过找出这些无法到达的对象是什么以及它们来自哪里？
我遇到内存泄漏的主要问题是 IO 流。检查你是否忘记关闭它们。注意：即使您将变量设置为 null，它们也会保留在内存中（当然，如果您不关闭）
问题是我不知道如何检查无法访问的对象来自哪里，因为它们无法访问。能给我一些建议吗？

标签： java memory memory-leaks heap-dump

【解决方案1】：

如果您在内存耗尽时有堆转储，我建议使用 MAT 来查找任何可疑的支配树，这是指向较大保留集大小的狭窄参考路径。

可能是相同的类在不同的类加载器中结束，或者如果 Web 应用程序或缓存问题出现问题，则可能是 HTTP 会话保留。

我建议你，先从简单的事情开始。

快速查看 jar 的加载对象和位置。
确保已启用类卸载（使用 CMS）。
使用堆转储上的内存分析器工具来准确查看保留的内容以及由谁保留。

【讨论】：

1. amazon.com/photos/share/… 2. amazon.com/photos/share/… 我用MAT分析了hprof文件。但正如我所说，MAT 跳过了很多无法访问的对象。如第二张图片所示，无法访问的对象占用了将近 3 GB。我认为标志 CMSClassUnloadingEnabled 会有所帮助，但我有一个问题是 CMSClassUnloadingEnabled 在 JVM 1.8 中默认启用？我也在尝试使用 visualVM 来分析 hprof 文件。
您可以使用-XX:+PrintFlagsFinal 选项显示HotSpot 最终用于运行Java 代码的选项，而-XX:+PrintFlagsInitial 显示最初提供给HotSpot 的选项。例如java -XX:+PrintFlagsFinal -version | grep -iE 'CMSClassUnloadingEnabled' 会告诉你它是启用还是禁用。
Dominator Tree 视图将列出每个对象实例与引用树结构的关系。您可以找到几个对象占用的最大内存量百分比。只是一个提示，你可能会发现一些东西！
非常感谢。我检查了 java -XX:+PrintFlagsFinal -version | grep -iE 'CMSClassUnloadingEnabled'。它表明 bool CMSClassUnloadingEnabled = true {product}
CMSClassUnloadingEnabled 好像开启了。