G1 vs CMS vs平行GC

这篇文章是我们一年前进行的实验的跟进，比较了现实环境中不同GC算法的性能。我们进行了相同的实验，将测试扩展为包含G1垃圾收集器，然后在不同的平台上运行了测试。今年，我们的测试使用了以下垃圾收集器：

-XX：+ UseParallelOldGC
-XX：+ UseConcMarkSweepGC
-XX：+ UseG1GC

环境说明

实验是在现成的JIRA配置上进行的。进行测试的动机非常明确-Minecraft，基于Dalvik的Angry Bird和Eclipse助手JIRA应该是其中最受欢迎的Java应用程序之一。与替代方案相反，它是我们大多数人在日常业务中处理的更典型的代表–毕竟，到目前为止，服务器端Java EE应用程序中仍然使用最多的Java。

也影响了我们决定的是– Atlassian的工程师在JIRA下载中很好地打包了负载测试。因此，我们有一个基准可用于我们的配置。

我们仔细解压缩了最新的JIRA 6.1下载文件，并将其安装在Mac OS X Mavericks上。并运行捆绑的测试，而不更改默认内存设置中的任何内容。 Atlassian团队非常友善，可以为我们提供服务：

-Xms256m -Xmx768m -XX:MaxPermSize=256m

测试以不同的通用方式使用JIRA功能-创建任务，分配任务，解决任务，搜索和发现任务等。测试的总运行时间为30分钟。

我们使用三种不同的垃圾收集算法进行了测试-在我们的案例中使用了Parallel，CMS和G1。每次测试均以全新的JVM引导开始，然后将存储预填充为完全相同的状态。只有在准备工作完成后，我们才开始生成负载。

结果

+ PrintGCTimeStamps -Xloggc：在各试验期间，我们使用-XX收集GC日志/tmp/gc.log -XX：+ PrintGCDetails和分析本次统计的帮助下GCViewer

结果可以汇总如下。请注意，所有度量单位均为毫秒：

	平行	内容管理系统	G1
总GC暂停时间	20930	18870	62 000
最大GC暂停	721	64	50

解释与结果

第一站–并行GC（ -XX：+ UseParallelOldGC ）。在完成测试所需的30分钟中，我们用并行收集器在GC暂停上花费了将近21秒。最长的暂停时间为721毫秒。因此，让我们以此为基准：GC周期将吞吐量减少了总运行时间的1.1％ 。 最坏情况下的延迟是721ms 。

下一位参赛者：CMS（ -XX：+ UseConcMarkSweepGC ）。同样，经过30分钟的测试，我们损失了不到19秒的GC时间。在吞吐量方面，这与并行模式大致处于同一邻域。另一方面，延迟得到了显着改善– 最坏情况下的延迟减少了10倍以上！ 现在，GC面临的最大暂停时间仅为64毫秒 。

上一个实验使用了可用的最新最明亮的GC算法– G1（ -XX：+ UseG1GC ）。运行了非常相同的测试，并且在吞吐量方面，我们看到结果严重受损。这次，我们的应用程序花费了超过一分钟的时间来等待GC完成。 与CMS的仅1％的开销相比，我们现在面临的通量影响接近3.5％ 。但是，如果您真的不关心吞吐量，并且想从延迟中挤出最后一点，那么-与已经不错的CMS相比，我们提高了约20％ -使用G1可以看到最长的GC暂停仅花费了50ms。