如何用常见的泄漏嫌疑人分析堆转储

Question

应用程序遇到缓慢问题并生成一些heapdump 文件，heapdump 文件为 1.2GB，我需要使用 8.4GB RAM 运行我的ha456.jar 才能打开堆转储。

在此之前，当我分析heapdump 时，我会尝试查看更大的LeakSize 并检查Leak Suspect 值，我可以看到我的应用程序的哪个类或哪个方法持有大内存。然后我会尝试修复代码，使其能够以更好的性能运行。

这次，我真的无法弄清楚我的应用程序的哪个模块/方法导致了内存不足的问题。以下是我HeapAnalyzer的部分截图：

对我来说，它只是普通的类，例如 java/lang/object、java/lang/Long 或 java/util/HashMap。我真的不知道我的应用程序的哪种方法导致内存不足。

感谢您就如何对此进行分析提出建议。

Answer 1

在代码前面的任何人都很难找到内存泄漏，更不用说到目前为止了。所以我只能给你一些建议：

1. 您有一个堆转储，按您的自己的对象过滤并分析谁创建了最多的对象
2. 运行您的应用程序并使用 VisualVM 对其进行监控，稍微使用该应用程序，然后强制运行 GC...10 次中有 9 次没有显着减少或未完全重置的对象是您的内存泄漏

Answer 2

这可能是由于从数据库之类的地方读取了很多记录，队列是 Long 类型。可能有笛卡尔连接或类似的东西。一旦我有大量的字符串导致 oom 并且罪魁祸首是一个记录器累积日志。

一些想法- 当你得到 oom 错误跟踪到可疑方法时。 获取线程转储并查看哪些线程处于活动状态以及它们正在执行什么。