jdk8 cms g1gc

这篇文章是我们一年前进行的实验的跟进，比较了现实环境中不同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引导开始，然后将存储预填充到完全相同的状态。 仅在进行准备后，我们才开始生成负载。

结果

在每次运行期间，我们使用-XX：+ PrintGCTimeStamps -Xloggc：/tmp/gc.log -XX：+ PrintGCDetails收集了GC日志，并在GCViewer的帮助下分析了此统计信息

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

解释与结果

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

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

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

结论

与往常一样，试图将这样的实验总结为一个结论是危险的。 因此，如果您有时间和需要的技能–一定要继续测量自己的环境，而不是采用一刀切的解决方案。

但是，如果我敢于做出这样的结论，我会说CMS仍然是最好的“默认”选项。 G1吞吐量仍然差得多，以至于延迟通常不值得。

翻译自: https://www.javacodegeeks.com/2013/12/g1-vs-cms-vs-parallel-gc.html

jdk8 cms g1gc