這篇文章是我們一年前進行的實驗的跟進，比較了現實環境中不同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。

結論

與往常一樣，試圖將這樣的實驗總結為一個結論是危險的。 因此，如果您有時間和必要的技能–一定要繼續測量自己的環境，而不是采用一刀切的解決方案。

但是，如果我敢于做出這樣的結論，我會說CMS仍然是最好的“默認”選項。 G1吞吐量仍然差得多，以至于延遲通常不值得。

參考： Plumbr博客博客上的JCG合作伙伴 Nikita Salnikov Tarnovski的 G1 vs CMS vs Parallel GC 。

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的G1 vs CMS vs平行GC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。