我的 Java 存在内存泄漏，堆转储中有 9600 个 ImapClient，而只有 7800 个 MonitoringTask。这是一个问题，因为每个 ImapClient 都应该属于 MonitoringTask，因此额外的 1800 个 ImapClient 会被泄露。
一个问题是我无法将它们隔离在堆转储中并查看是什么让它们保持活力。到目前为止，我只能通过使用外部证据来猜测哪些 ImapClient 悬空来查明它们。我正在学习 OQL，我相信它可以解决这个问题，但它进展缓慢，我需要一段时间才能理解如何在新的查询语言中执行这样的递归操作。
确定是否存在泄漏很困难，所以这是我的完整情况:
- 这个过程一周前就已经引发了 OOME。我以为我已经修复了它，并且正在尝试验证我的修复是否有效，而无需再等待整整一周来查看它是否再次喷出 OOME。
- 此任务在启动时创建 7000-9000 个
ImapClient，然后在正常操作下连接和断开其中的极少数。 - 我检查了另一个运行旧版 OOME 之前代码的进程，它显示的数字是 9000/9100，而不是 7800/9600。我不知道为什么旧代码会与新代码不同，但这是泄漏的证据。
这个问题的目的是让我可以确定是否存在泄漏。有一条业务规则:每个 ImapClient 都应该是 MonitoringTask 的裁判。如果我询问的这个查询结果为空，则没有泄漏。如果它提出了对象以及此业务规则，那么它不仅是泄漏的证据，而且是确实的泄漏证据。
最佳答案
您的期望不正确，没有实际证据表明发生任何泄漏
The Garbage Collector's goal is to free space when it is needed and only then, anything else is a waste of resources. There is absolutely no benefit in attempting to keep as much free space as possible available all the time and only down sides.
Just because something is a candidate for garbage collection doesn't mean it will ever actually be collected, and there is no way to force garbage collection either.
我在任何地方都没有看到任何提及 OutOfMemoryError 的内容。
你所关心的事情是你无法控制的，无论如何也不能直接控制
您应该关注的是您可以控制的内容，即确保您保留引用文献的时间不会超过您需要的时间，并且不会不必要地重复内容。 Java 中的垃圾收集例程是高度优化的，如果您了解它们的算法如何工作，您可以确保您的程序以适合这些算法工作的最佳方式运行。
Java 堆内存与其他语言中手动管理的内存不同，这些规则不适用
其他语言中被视为内存泄漏的内容与 Java 及其垃圾收集系统中的内存泄漏不同/根本原因。
Java 内存很可能不会被泄漏的单个 super 对象消耗(其他环境中的悬空引用)。
中间对象的保留时间可能比垃圾收集器预期的时间长，因为它们所处的范围以及许多其他事情在运行时可能会发生变化。
示例:垃圾收集器可能会决定存在候选者，但因为它认为仍有大量内存可供使用，因此此时将其清除可能会花费太多时间时间点，它会等到内存压力变大。
垃圾收集器现在确实很好，但它并不神奇，如果你在做退化的事情，它会导致它无法最佳地工作。 Internet 上有大量有关所有 JVM 版本的垃圾收集器设置的文档。
这些未引用的对象可能还没有达到垃圾收集器认为需要将它们从内存中删除的时间，或者可能有其他对象(List )例如，您没有意识到仍然指向该对象。这就是 Java 中最常见的泄漏，更具体地说是引用泄漏。
我没有看到任何提及 OutOfMemoryError
您的代码中可能没有问题，垃圾收集系统可能没有承受足够的压力来启动并释放您认为应该清理的对象。 您认为的问题可能并不是问题，除非您的程序因OutOfMemoryError而崩溃。这不是 C、C++、Objective-C 或任何其他手动内存管理语言/运行时。您无法按照您期望的详细级别来决定内存中包含哪些内容或不在内存中。
关于Java 内存泄漏 - 查找类 X 未被类 Y 引用的所有对象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21683709/