JVM OutOfMemory错误“死亡螺旋”（不是内存泄漏）

Question

我们最近一直在将许多应用程序从RedHat linux JDK1.6.0_03下运行迁移到Solaris 10u8
JDK1.6.0_16（规格更高的机器），并且我们注意到了一个似乎很紧迫的问题：在某些负载下，我们的JVM获得了自己陷入“死亡螺旋”，并最终失去记忆。注意事项：

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

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

听起来很疯狂，但我只是看不到其他东西。您还能如何解释一个应用程序，该应用程序在一分钟内崩溃，最大堆容量为1Gb，而下一分钟工作正常（当应用程序做
完全相同的事情 时，永远不会达到256M左右）

所以我的问题是：

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

Answer 1

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

您是否尝试过更改正在使用的垃圾收集器？有很多GC选项，弄清楚哪个是最佳选择，似乎有点不明智，但是我想知道是否有一个基本的更改对您有用。

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

对于您的特定情况，线程GC（我相信这是默认值）可能是最糟糕的，我注意到，当计算机繁忙时，它的攻击性通常会降低。

我注意到的一件事，通常需要两个GC才能说服Java真正清除垃圾。我认为第一个倾向于取消链接一堆对象，第二个实际上删除它们。您可能要执行的操作有时是强制两个垃圾回收。这将导致大量的GC暂停，但是我从未见过要花费两个以上的时间来清理整个堆的情况。