Java非常大的堆大小[关闭]

有人有在 Java 中使用非常大的堆（12 GB 或更大）的经验吗？

• GC 是否会使程序无法使用？
• 您使用什么 GC 参数？
• Sun 或 BEA 哪一个 JVM 更适合于此？
• Linux 和 Windows 哪个平台在这种条件下表现更好？
• 就 Windows 而言，在如此高的内存负载下，64 位 Vista 和 XP 之间是否存在性能差异？

如果您的应用程序不是交互式的，并且 GC 暂停对您来说不是问题，那么 64 位 Java 处理非常大的堆（即使是数百 GB）应该不会有任何问题。我们还没有注意到 Windows 或 Linux 上有任何稳定性问题。

然而，当您需要保持 GC 暂停时间较低时，事情会变得非常糟糕：

1. 忘记默认吞吐量，停止 GC。对于中等堆 ( ~30 GB)，它会暂停您的应用程序几分钟。购买更快的 DIMM 也无济于事。

2. 最好的选择可能是 CMS 收集器，由 -XX:+UseConcMarkSweepGC 启用。 CMS 垃圾收集器仅在初始标记阶段和重新标记阶段停止应用程序。对于像

3. 当 CMS 垃圾收集器的速度不够快，无法在终身代填满之前完成操作时，它会回退到标准的 stop-the-world GC。对于大小为 16 GB 的堆，预计会有大约 30 秒或更长的暂停时间。您可以尝试避免这种情况，使应用程序的长期垃圾产生率尽可能低。请注意，运行应用程序的核心数量越多，此问题就越严重，因为 CMS 仅使用一个核心。显然，要小心有no保证 CMS 不会回退到 STW 收集器。当它发生时，它通常发生在峰值负载时，并且您的应用程序会死机几秒钟。您可能不想为此类配置签署 SLA。

4. 嗯，有新的 G1 东西。理论上它是为了避免 CMS 的问题而设计的，但我们已经尝试过并观察到：

   • 它的吞吐量比CMS差。
   • 从理论上讲，它应该首先避免收集流行的内存块，但是它很快就会达到几乎所有块都是“流行”的状态，并且它所基于的假设完全停止工作。
   • 最后，G1 的 stop-the-world 后备方案仍然存在；询问 Oracle，该代码应该何时运行。如果他们说“从不”，请询问他们为什么代码在那里。所以恕我直言，G1 确实并没有让 Java 的巨大堆问题消失，它只是让它（可以说）变得更小了一些。

5. 如果您有钱购买具有大内存的大型服务器，那么您可能也有钱购买良好的商业硬件加速、无暂停 GC 技术，例如 Azul 提供的技术。我们有一台具有 384 GB RAM 的服务器，它确实工作得很好 - 没有暂停，GC 中只有 0 行 stop-the-world 代码。

6. 用 C++ 编写应用程序中需要大量内存的部分，就像 LinkedIn 在社交图处理中所做的那样。这样做仍然无法避免所有问题（例如堆碎片），但保持较低的暂停肯定会更容易。