通过 JProfiler 查找内存泄漏答案

【问题标题】：Finding memory leak By JProfiler通过 JProfiler 查找内存泄漏
【发布时间】：2012-03-13 16:01:50
【问题描述】：

我的问题不同于 this 我已经完成了我的应用程序的分析，它太慢了。
完成一个进程后，我在堆遍历器中看到了一些活动对象。

虽然我们将一些数据从数据库缓存到 HashMap，但堆遍历器向我显示了一些活动对象，例如 Resultset.getString 和 Statement.getString，它们不应该存在。

HashMap.put() 占用的内存比上述两种方法要少。

我做的一切都很好吗？这个分析对吗？或者我遗漏了任何东西，内存被HashMap 本身占用，HeapWalker 只是向我展示了 JDBC 的方法（getString 和 executeQuery）。

【问题讨论】：

【解决方案1】：

既然您在谈论方法，我猜您正在查看堆遍历器的“分配”视图。该视图显示对象被创建的位置，而不是对象被引用的位置。 explains allocation recording in JProfiler 有一个截屏。

HashMap.put 不会分配大量内存，它只是创建用于存储键值对的小型“条目”对象。占用大量内存的对象是在将它们放入哈希映射之前创建的。

Resultset.getString 和 Statement.getString 创建您从数据库中读取的 String 对象。因此可以合理地假设其中一些对象的寿命更长。

要找出为什么对象仍在堆上，您应该转到引用视图，选择传入的引用并搜索“GC 根路径”。 “最大的对象”视图对于追踪过多的内存使用也很有帮助。

【讨论】：

谢谢 Ingo 很长一段时间以来，我一直在看到你提供与 JProfiler 相关的良好答案。我期待你的回答。我有一个问题 - 做这些对象（结果集和声明) 应该在您的数据库进程完成后在堆中...？
@NIVESHSENGAR 不，他们不应该真的在堆上
还有一个问题，我正在使用 hashmap 来缓存一些数据，它通常在我们登录时填充。它填充完美，但它的大小不断增长。当 GC 调用它的大小时，它的大小减小了，但过了一段时间它又开始迅速增加。是不是内存泄漏
@NIVESHSENGAR 是的，随着时间的推移无限增长的缓存将被视为内存泄漏

【解决方案2】：

您可能看到的是连接（可能是其缓冲区缓存）或语句或结果集所保存的缓存数据。

这可能是由于未关闭连接、语句或结果集，也可能是由于连接池。如果您查看内存配置文件，您可能会看到“到 GC 根目录的路径”（对象根目录的路径），这将表明您的 ResultSet 字符串是什么。您应该查看它是否在您的代码中，是否缓存在您保留的内容中，或者是否在池中。

注意我没有使用过 JProfiler，但这就是我使用 YourKit 跟踪它的方式。

【讨论】：