Java 内存泄漏 - 查找所有未被类 Y 引用的类 X 的对象

Question

我在 Java 中有内存泄漏，我的堆转储中有 9600 个 ImapClient 而只有 7800 个 MonitoringTask。这是一个问题，因为每个 ImapClient 都应该由一个 MonitoringTask 拥有，所以那些额外的 1800 个 ImapClient 被泄露了。

一个问题是我无法将它们隔离在堆转储中并查看是什么让它们存活。到目前为止，我只能通过使用外部证据来猜测哪些 ImapClient 悬而未决来查明它们。我正在学习 OQL，我相信它可以解决这个问题，但它进展缓慢，我需要一段时间才能理解如何在新的查询语言中执行类似这样的递归操作。

确定泄漏存在很困难，所以这是我的完整情况:

• 这个过程一周前就出现了 OOME。我以为我修复了它，我正在尝试验证我的修复是否有效，而不是再等整整一周看看它是否再次喷出 OOME。
• 此任务在启动时创建 7000-9000 个 ImapClient，然后在正常操作下连接和断开其中的极少数。
• 我检查了另一个运行较旧的 OOME 前代码的进程，它显示的数字是 9000/9100 而不是 7800/9600。我不知道为什么旧代码会与新代码不同，但这是泄漏的证据。

这个问题的重点是我可以确定是否存在泄漏。有一个业务规则，每个 ImapClient 都应该是 MonitoringTask 的裁判。如果我问的这个查询是空的，则没有泄漏。如果它拿出对象，再加上这个业务规则，它不仅是泄漏的证据，而且是泄漏的决定性证据。

Answer 1

您的预期不正确，没有任何泄漏发生的实际证据

The Garbage Collector's goal is to free space when it is needed andonly then, anything else is a waste of resources. There is absolutelyno benefit in attempting to keep as much free space as possibleavailable all the time and only down sides.

Just because something is a candidate for garbage collection doesn'tmean it will ever actually be collected, and there is no way toforce garbage collection either.

我在任何地方都没有看到任何关于 OutOfMemoryError 的提及。

你所关心的是你无法控制的，无论如何也不能直接控制

您应该关注的是在您的控制范围内的内容，即确保您保留引用的时间不会超过您需要的时间，并且不会不必要地重复内容。 Java 中的垃圾收集例程经过高度优化，如果您了解其算法的工作原理，则可以确保您的程序以最佳方式运行，以使这些算法能够正常工作。

Java 堆内存不像其他语言中的手动管理内存，这些规则不适用

在其他语言中被认为是内存泄漏的东西与 Java 中的垃圾收集系统不同/根本原因。

在 Java 中，内存很可能不会被一个正在泄漏的 super 对象消耗(在其他环境中是悬空引用)。

中间对象的保留时间可能比垃圾收集器预期的要长，因为它们所处的范围以及运行时可能会发生变化的许多其他因素。

示例: 垃圾收集器可能会决定有候选对象，但因为它认为仍有大量内存可用，所以此时清除它们可能太费时间了时间点，它会等到内存压力变大。

垃圾收集器现在真的很好，但它并不神奇，如果你在做退化的事情，它会导致它无法最佳地工作。互联网上有很多关于所有 JVM 版本的垃圾收集器设置的文档。

这些未引用的对象可能还没有到达垃圾收集器认为需要它们从内存中删除的时间，或者可能有其他对象持有对它们的引用(List )例如你没有意识到仍然指向那个对象。这就是 Java 中最常提到的泄漏，更具体地说是引用泄漏。

我没有看到任何提及 OutOfMemoryError

您的代码中可能没有问题，垃圾收集系统可能没有承受足够的压力来启动和释放您认为应该清理的对象。 您认为 是个问题可能不是，除非您的程序因OutOfMemoryError 而崩溃。这不是 C、C++、Objective-C 或任何其他手动内存管理语言/运行时。您无法在您期望的细节级别上决定内存中的内容或不在内存中的内容。