java中的内存泄漏[关闭]答案

【问题标题】：Memory leak in java [closed]java中的内存泄漏[关闭]
【发布时间】：2012-10-20 13:50:00
【问题描述】：

我使用 jprofiler 来检测我的客户端代码的内存泄漏。在启动时 java.util.hashmap$entry 使用的内存急剧增加到 1700KB。之后它也减少了。堆转储显示 java.lang.ref.finalizer 正在使用最大内存。它得出什么结论？当我尝试在我的源代码中找到 finalize() 时，它不存在。在 HTML 文件中 finalize() 是这样使用的。 finalize，这是什么意思？原因是finalize()还是引用hashmap$entry导致泄露？

【问题讨论】：

没有java.lang.ref.finalizer 或java.util.hashmap$entry 这样的东西。请用真实的类名或方法名或任何它们更新问题。
为什么会出现内存泄漏？您的应用程序是否给您OutOfMemoryException？也许您只需要更改启动应用程序的内存量。

标签： java memory-leaks jprofiler finalize

【解决方案1】：

它的结论是什么？

首先，你所谓的“证据”是乱码，不清楚应该是什么无乱码的版本。然而，基于一些猜测......我根本看不到内存泄漏的明显迹象。

相反，看起来如果你有一个大的WeakHashMap，要么变得无法访问，要么因为 GC 注意到堆太满而被清除，会发生什么情况。

但是，我的猜测可能是错误的，这里可能有泄漏......

原因是finalize()还是引用hashmap$entry导致泄露？

也不一定。（事实上，如果确实存在存储泄漏，那么不太可能其中任何一个都是直接原因。）

【讨论】：

谢谢斯蒂芬。实际上几乎每一种数据数据类型的内存消耗值都在增加。我的意思是说，如果在 10 分钟后消耗现在为 50kb，则为 56kb，而在执行 gc 之后，消耗为 53kb，这意味着在 10 分钟后，内存增加了 3 kb，并且仅以这种方式定期增加。它是否确认我的应用程序存在内存泄漏？
单个数据点不是内存泄漏的证据。一致的长期趋势将是泄漏的证据。

【解决方案2】：

如果您想查找内存泄漏，您应该查看在 Full GC 之后使用了多少内存，如果您有很多可终结的引用，则查看两次，否则您可能会看到很多临时对象没有问题。

我怀疑您看到的这两种数据类型都不是问题，尤其是如果它们定期减少使用。寻找只会上升的消费。

【讨论】：

谢谢彼得。实际上几乎每种数据数据类型的内存消耗值都在增加。我的意思是说，如果在 10 分钟后消耗现在为 50kb，则为 56kb，而在执行 gc 之后，消耗为 53kb，这意味着在 10 分钟后，内存增加了 3 kb，并且仅以这种方式定期增加。它是否确认我的应用程序存在内存泄漏？
Full GC 后增加许多 MB 可能是泄漏。我不会担心几 KB，因为它可能是“噪音”。如果一切都在增加，它指向一个共同因素，例如一个包含所有这些不断增加的类的集合。