java - JVM OutOfMemory 错误 "death spiral"(不是内存泄漏)

Question

我们最近将许多应用程序从在 RedHat linux JDK1.6.0_03 下运行的迁移到 Solaris 10u8 JDK1.6.0_16(更高规范的机器)，我们注意到一个似乎相当紧迫的问题:在某些负载下我们的 JVM 让自己陷入“死亡螺旋”并最终耗尽内存。注意事项:

• 这不是内存泄漏的情况。这些应用程序运行良好(在一种情况下运行了 3 年以上)，内存不足错误在任何情况下都不确定。应用程序有时工作，有时不工作
• 这不是我们迁移到 64 位 VM - 我们仍在运行 32 位
• 在一种情况下，在 1.6.0_18 上使用最新的 G1 垃圾收集器似乎已经解决了这个问题。另一方面，回到 1.6.0_03 已经奏效
• 有时我们的应用会因 HotSpot SIGSEGV 错误而崩溃
• 这会影响用 Java 和 Scala 编写的应用程序

最重要的一点是:这种行为表现在那些突然获得大量数据(通常通过 TCP)的应用程序中。就好像 VM 决定继续添加更多数据(可能将其推进到 TG)，而不是在“新空间”上运行 GC，直到它意识到它必须执行完整的 GC，然后，尽管几乎所有内容都在VM 是垃圾，它以某种方式决定不收集它!

这听起来很疯狂，但我只是看不出还有什么。你怎么能解释一个应用程序在最大堆为 1Gb 的情况下一分钟崩溃而下一个工作正常(当应用程序执行完全相同的事情时，永远不会达到大约 256M)

所以我的问题是:

1. 有其他人观察到这种行为吗？
2. 对我如何调试 JVM 本身(而不是我的应用程序)有任何建议吗？如何证明这是 VM 问题？
3. 是否有任何 VM 专家论坛，我可以在其中询问 VM 的作者(假设他们不在 SO 上)？ (我们没有支持契约(Contract))
4. 如果这是最新版本的 VM 中的错误，为什么没有其他人注意到它？

Answer 1

有趣的问题。听起来其中一个垃圾收集器在您的特定情况下效果不佳。

您是否尝试过更改正在使用的垃圾收集器？有很多 GC 选项，找出哪些是最优的似乎有点玄学，但我想知道一个基本的改变是否适合你。

我知道有一个“服务器”GC 往往比默认的更好。你在用吗？

线程 GC(我认为这是默认设置)对于您的特定情况可能是最糟糕的，我注意到当机器繁忙时它往往不那么激进。

我注意到一件事，通常需要两次 GC 才能说服 Java 真正取出垃圾。我认为第一个倾向于取消链接一堆对象，第二个实际上删除了它们。您可能想要做的是偶尔强制进行两次垃圾回收。这将导致严重的 GC 暂停，但我从未见过需要两次以上才能清理整个堆的情况。