Java 的串行垃圾收集器性能比其他垃圾收集器好得多？

Question

我正在测试一个用 Java 编写的 API，它有望最大限度地减少处理通过网络接收的消息时的延迟。为了实现这些目标，我正在使用各种可用的垃圾收集器。

我正在尝试四种不同的技术，它们利用以下标志来控制垃圾收集:

1)序列号:-XX:+UseSerialGC

2)并行:-XX:+UseParallelOldGC

3)并发:-XX:+UseConcMarkSweepGC

4)并发/增量:-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing

我在五个小时的过程中运行了每项技术。我定期使用 ManagementFactory.getGarbageCollectorMXBeans() 提供的 GarbageCollectorMXBean 列表来检索收集垃圾所花费的总时间。

我的结果？请注意，此处的“延迟”是“我的应用程序+API 处理每条从网络上获取的消息所花费的时间。”

串行:789 次 GC 事件，总计 1309 毫秒；平均延迟 47.45 us，中值延迟 8.704 us，最大延迟 1197 us

并行:1715 个 GC 事件总计 122518 毫秒；平均延迟 450.8 us，中值延迟 8.448 us，最大延迟 8292 us

并发:4629 个 GC 事件总计 116229 毫秒；平均延迟 707.2 us，中值延迟 9.216 us，最大延迟 9151 us

增量:5066 次 GC 事件总计 200213 毫秒；平均延迟 515.9 us，中值延迟 9.472 us，最大延迟 14209 us

我发现这些结果是如此不可能，以至于它们近乎荒谬。有谁知道为什么我会得到这些结果？

哦，郑重声明，我使用的是 Java HotSpot(TM) 64 位服务器虚拟机。

Answer 1

I'm working on a Java application that is expected to maximize throughput and minimize latency

两个问题:

• 这些通常是相互矛盾的目标，因此您需要确定每个目标相对于另一个的重要性(您会牺牲 10% 的延迟来获得 20% 的吞吐量增益，还是相反？您的目标是一些特定延迟目标，超过这个目标是否更快并不重要？诸如此类。)
• 你还没有给出关于这些任一个的任何结果

您所显示的只是在垃圾收集器上花费了多少时间。如果您实际上实现了更高的吞吐量，您可能期望看到更多时间花在垃圾收集器上。或者换句话说，我可以更改代码以非常轻松地最小化您报告的值:

// Avoid generating any garbage
Thread.sleep(10000000);

您需要弄清楚什么对您来说实际上是重要的。衡量所有重要的事情，然后找出权衡所在。因此，第一要做的是重新运行测试并测量延迟和吞吐量。您可能也关心 CPU 总使用率(当然这与 GC 中的 CPU 不同)但是当您没有衡量您的主要目标时，您的结果并没有给您特别有用的信息.