有谁知道 Java 的新垃圾优先 (G1) 垃圾收集器（与“旧”GC 相比）的任何性能基准？
在 GC 暂停时间方面，Sun 表示 G1 有时比 CMS 更好，有时更差。虽然 G1 收集器成功地限制了总暂停时间，但它仍然只是一个软实时收集器。换句话说，它不能保证它不会一直影响应用程序线程满足其最后期限的能力。但是，它可以在一组明确定义的范围内运行，这使其成为需要保持高吞吐量性能的软实时系统的理想选择。
我想看看 Java 的 CMS（并发标记扫描）和 G1（垃圾优先）收集器的吞吐量和延迟的实际测量值。
【问题讨论】：
标签： java performance garbage-collection
原始科学文章（Detlefs、Flood、Heller 和 Printezis 的"Garbage-First Garbage Collection"）包含有关实际措施的一些详细信息（在第 4 节中）。
【讨论】：
我们刚刚使用类似的人体工程学对 CMS 和 G1 进行了一系列测试。这是特定于产品且非常主观的，而且我们使用的是 Java 6（因此 G1 处于“预览”版本中）但是...
使用 CMS 的系统比 G1 快 20%。这是使用 8GB 和 12GB 堆空间以及 1GB 和 1.5GB 新空间（分别）进行测试的。
再说一遍 - 主观、单一系统、特定负载 - 但这是我们的经验。
【讨论】：
更新：见下文
如果您有一个 Web 应用程序，或者另一个处理大量客户端/请求的应用程序，并且响应时间对您很重要，那么您最好使用 CMS。 此测试在“Java 性能和可扩展性”中找到
更新日期：2019 年 11 月 18 日
这里比较了每个垃圾收集器的暂停。 它是 2019 年，我认为 WebApp 的最佳选择仍然是 CMS，直到您可以直接切换到 ShenandoahGC（跳过 G1）
请务必了解，GC 暂停可能不是影响常规应用程序响应时间的唯一重要因素。较大的 GC 暂停很可能会导致响应时间问题，但没有较长的 GC 暂停并不总是意味着适当的响应时间。排队延迟、网络延迟、其他服务延迟、操作系统调度程序抖动等可能是造成成本的原因。建议运行带有响应时间测量的 Shenandoah 以全面了解系统中发生的情况，然后可以将其用于与 GC 暂停时间统计信息相关联。
例如，这是一个带有 jHiccup 的关于其中一个工作负载的示例报告：
【讨论】：
Taranfx article (2009-08-29) 在 4 个简单的基准测试中比较了 Java 5、6 和 7 的性能。
【讨论】：
由于多线程的概念，G1 与 CMS 相比更快。与我不知道的 Parallel-GC 相比 - 它可能是相同的。 当然，G1 更实时，因为没有两种线程在运行（主要是小线程）。它更快，因为任何线程都应该对性能产生相同的影响。甚至压缩也仅在复制时完成。 有关更多详细信息，请仔细查看： http://geekroom.de/java/java-expertise-g1-fur-java-7/
【讨论】：