Java GC 线程瓶颈在实践中？答案

【问题标题】：Java GC Threading Bottleneck in Practice?Java GC 线程瓶颈在实践中？
【发布时间】：2011-03-24 08:41:56
【问题描述】：

Java 对多线程环境的并行收集 GC 的优化程度如何？我编写了一些多线程 Jython 代码，大部分时间都在调用 Java 库。根据我运行程序的选项，库调用要么在后台进行大量分配，要么几乎没有。当我使用需要大量堆分配的选项时，我无法让代码扩展到超过 6 个内核。当我使用不需要大量分配的选项时，它至少可以扩展到 20 个。考虑到我使用的是 Sun VM、并行 GC 和 Jython，这与 GC 瓶颈有关的可能性有多大作为我的胶水语言？

编辑：澄清一下，我不一定会想到对 Java 资深人士来说显而易见的东西，因为我几乎从不使用 Java/JVM 语言。我的大部分编程都是用 D 和 Python 的旗舰 CPython 实现。我将 JVM 和 Jython 用于一个小型一次性项目 b/c 我需要访问 Java 库。

【问题讨论】：

您使用哪些选项？这似乎是 ThreadPool 问题，而不是 GC 问题。
@Thierry：这些选项特定于我的程序，就调用了哪些库函数而言。我什至没有使用线程池。

标签： java multithreading garbage-collection jython parallel-processing

【解决方案1】：

由于您的问题是关于 GC 瓶颈：您可以通过打开 GC 日志记录并检查日志来消除这种可能性 - 如果有大量 GC 事件且暂停时间较长，您可以确认/打折这个理论。（但是，在您描述的场景中，我猜这不是 GC 问题）。

【讨论】：

谢谢，我不知道访问 GC 所做工作的人类可读日志是如此容易，直到您指出我并用谷歌搜索它。在 D 中绝对不是那么容易，在 CPython 中 AFAIK 也不是那么容易。日志明确说明了一件事：GC 每秒运行几次。我对代码的扩展性感到惊讶。

【解决方案2】：

对我来说，GC 和多线程的问题是非常真实的。我并不是说 JVM 不好，只是问题本身很难处理。

在我们的一个项目中，我们有两个应用程序在单个 JVM（应用程序服务器）中运行。当单独给它们施加压力时，这很好，但是当它们一起施加压力时，性能会以一种奇怪的方式下降。我们最终拆分了应用程序。在两个 JVM 中，性能恢复正常（当然比只使用一个应用程序时要慢，但合理）。

调整 GC 非常困难。事情可以改善 5 分钟，然后一个主要的集合会阻塞，等等。您可以决定在操作中是想要高吞吐量还是低延迟。高吞吐量适合批处理，低延迟对于交互式应用程序是必要的。最终，JVM 的默认参数对我们来说是最好的结果！

这并不是真正的答案，而是经验的回报，但对我来说，GC 和多线程可能是个问题。

【讨论】：

我知道存在 GC/多线程问题，但 Java 的 GC 是高度精炼的，并且从我认为的 Java 作为一种语言的严格性（没有联合、原始指针等）中受益匪浅这些大多是已解决的问题。在 D 中，问题甚至更大，但由于我通常在 D 中编写更多“从头开始”的代码，而不是胶合代码，并且可以做更多的肮脏技巧来避免不必要的分配，它们也更容易解决。我认为，在当前项目中解决它们基本上意味着重写一个大型库。

【解决方案3】：

Java GC 是分代的。第一代的集合旨在处理短期对象，并预计会频繁运行。如果有许多短期分配，则每秒运行几次短时间间隔是预期的行为。（这应该是评论而不是答案 - 我没有代表，抱歉）。

此外，根据您使用的虚拟机，您可以在 GC 算法之间进行选择。这些选项将根据您使用的 VM 的版本和供应商而有所不同。

一些（旧）信息在这里：http://java.sun.com/developer/technicalArticles/Programming/turbo/#The_new_GC

【讨论】：

【解决方案4】：

线程性能可能因 jdk 版本而异。根据我的经验，在 jdk6u18 上，使用 -XX:+UseParallelGC（不是并发标记扫描 gc）启用的并行 gc 在具有数百个非常活跃的线程的四核上表现得非常好。我认为它不太可能扩展到超过 6 个核心。

Sun 的硬件基于具有大量内核的处理器这一事实解释了为什么他们近年来在新的垃圾收集器上投入了大量精力。

parallel gc默认不开启，因为单线程性能不如默认gc。

【讨论】：