java - 很奇怪的OutOfMemoryError

Question

一如既往，冗长的问题描述。

我们目前正在对我们的产品进行压力测试 - 现在我们面临一个奇怪的问题。一到两个小时后，堆空间开始增长，应用程序会在一段时间后死亡。

分析应用程序显示大量的 Finalizer 对象填满了堆。好吧，我们认为“可能是奇怪的终结器线程变慢了”问题，并审查了减少需要终结的对象数量(在这种情况下为 JNA native 句柄)。好主意，减少了数以千计的新对象......

接下来的测试显示了相同的模式，仅在一个小时后并且没有那么陡峭。这次 Finalizers 源自在测试平台中大量使用的 FileInput 和 FileOutput 流。所有资源都已关闭，但 Finalizer 不再清理。

我不知道为什么在 1 或 2 小时后(无一异常(exception))FinalizerThread 似乎突然停止工作。如果我们在某些线程中手动强制执行 System.runFinalization()，分析器会显示终结器已清理。立即恢复测试会导致为终结器分配新的堆。

FinalizerThread 仍然存在，询问 jConsole 他在等待。

编辑

首先，使用 HeapAnalyzer 检查堆没有发现任何新的/奇怪的东西。 HeapAnalyzer 有一些不错的功能，但我一开始遇到了困难。我使用的是 jProfiler，它附带了很好的堆检查工具，并将继续使用它。

也许我缺少 HeapAnalyzer 中的一些 killer 级功能？

其次，今天我们使用调试连接而不是分析器设置测试 - 系统现在稳定了将近 5 个小时。这似乎是太多终结器(在第一次审查中已减少)、分析器和 VM GC 策略的非常奇怪的组合。由于目前一切运行良好，没有真正的见解......

感谢到目前为止的输入 - 也许您会继续关注和感兴趣(现在您可能有更多理由相信我们不会讨论简单的编程错误)。

Answer 1

我想用当前状态的总结来结束这个问题。

最后一次测试现在已经超过 60 个小时没有任何问题。这使我们得出以下总结/结论:

• 我们有一个高吞吐量的服务器，它使用大量最终实现“最终确定”的对象。这些对象主要是 JNA 内存句柄和文件流。构建终结器的速度快于 GC 和终结器线程能够清理的速度，此过程在约 3 小时后失败。这是一个众所周知的现象(-> 谷歌)。
• 我们进行了一些优化，因此服务器摆脱了几乎所有的 JNA 终结器。此版本已通过附加的 jProfiler 进行测试。
• 服务器比我们最初的尝试晚了几个小时...
• 探查器显示了大量的终结器，这次主要是由文件流引起的。这个队列没有被清理，即使在服务器暂停一段时间后也是如此。
• 只有在手动触发“System.runFinalization()”后，队列才被清空。恢复服务器开始重新填充...
• 这仍然是无法解释的。我们现在猜测这是一些分析器与 GC/finalization 的交互。
• 为了调试可能是非 Activity 终结器线程的原因，我们这次分离了探查器并附加了调试器。
• 系统运行时没有明显缺陷...FinalizerThread 和 GC 都是“绿色”。
• 我们恢复了测试(现在又是第一次，除了 jConsole 之外没有附加任何代理)并且它现在正常运行了 60 多个小时。显然，最初的 JNA 重构解决了这个问题，只是分析 session 增加了一些不确定性(来自海森堡的问候)。

管理终结器的其他策略例如在 http://cleversoft.wordpress.com/2011/05/14/out-of-memory-exception-from-finalizer-object-overflow/ 中讨论。 (除了不太聪明的“不要使用终结器”……)。

感谢您的所有意见。