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的幫助下分析了此統計信息

結果可以匯總如下。 請注意，所有度量單位均為毫秒：

平行 不育系 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分鐘的測試中，GC損失了不到19秒。 在吞吐量方面，這與并行模式大致處于同一鄰域。 另一方面，延遲大大改善了– 最壞情況下的延遲減少了10倍以上！ 現在，GC面臨的最大暫停時間僅為64毫秒 。

上一個實驗使用了可用的最新最明亮的GC算法– G1（ -XX：+ UseG1GC ）。 運行了非常相同的測試，并且在吞吐量方面，我們看到結果嚴重受損。 這次，我們的應用程序花費了超過一分鐘的時間來等待GC完成。 與CMS的僅1％的開銷相比，我們現在面臨的通量影響接近3.5％ 。 但是，如果您真的不關心吞吐量，并且想從延遲中擠出最后一點，那么-與已經不錯的CMS相比，我們提高了約20％ -使用G1可以看到最長的GC暫停僅花費了50ms。

結論

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

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

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

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

jdk8 cms g1gc

總結

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

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