這篇文章是我們一年前進(jìn)行的實(shí)驗(yàn)的跟進(jìn)，比較了現(xiàn)實(shí)環(huán)境中不同GC算法的性能。 我們進(jìn)行了相同的實(shí)驗(yàn)，將測(cè)試擴(kuò)展為包含G1垃圾收集器，然后在不同的平臺(tái)上運(yùn)行了測(cè)試。 今年，我們的測(cè)試使用了以下垃圾收集器：

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

環(huán)境說明

實(shí)驗(yàn)是在現(xiàn)成的JIRA配置上進(jìn)行的。 進(jìn)行測(cè)試的動(dòng)機(jī)非常明確-Minecraft，基于Dalvik的Angry Bird和Eclipse助手JIRA應(yīng)該是其中最受歡迎的Java應(yīng)用程序之一。 與替代方案相反，它是我們大多數(shù)人在日常業(yè)務(wù)中處理的更典型的代表–畢竟，到目前為止，服務(wù)器端Java EE應(yīng)用程序中仍然使用最多的Java。

也影響了我們決定的是– Atlassian的工程師在JIRA下載中很好地打包了負(fù)載測(cè)試 。 因此，我們有一個(gè)基準(zhǔn)可用于我們的配置。

我們仔細(xì)解壓縮了最新的JIRA 6.1下載文件，并將其安裝在Mac OS X Mavericks上。 并運(yùn)行捆綁的測(cè)試，而不更改默認(rèn)內(nèi)存設(shè)置中的任何內(nèi)容。 Atlassian團(tuán)隊(duì)非常友善，可以為我們提供服務(wù)：

-Xms256m -Xmx768m -XX:MaxPermSize=256m

測(cè)試以不同的通用方式使用JIRA功能-創(chuàng)建任務(wù)，分配任務(wù)，解決任務(wù)，搜索和發(fā)現(xiàn)任務(wù)等。測(cè)試的總運(yùn)行時(shí)間為30分鐘。

我們使用三種不同的垃圾收集算法進(jìn)行了測(cè)試-在我們的案例中使用了Parallel，CMS和G1。 每次測(cè)試均以全新的JVM引導(dǎo)開始，然后將存儲(chǔ)預(yù)填充為完全相同的狀態(tài)。 只有在準(zhǔn)備工作完成后，我們才開始生成負(fù)載。

結(jié)果

+ PrintGCTimeStamps -Xloggc：在各試驗(yàn)期間，我們使用-XX收集GC日志/tmp/gc.log -XX：+ PrintGCDetails和分析本次統(tǒng)計(jì)的幫助下GCViewer

結(jié)果可以匯總?cè)缦隆?請(qǐng)注意，所有度量單位均為毫秒：

平行 內(nèi)容管理系統(tǒng) G1

總GC暫停時(shí)間	20930	18870	62 000
最大GC暫停	721	64	50

解釋與結(jié)果

第一站–并行GC（ -XX：+ UseParallelOldGC ）。 在完成測(cè)試所需的30分鐘中，我們用并行收集器在GC暫停上花費(fèi)了將近21秒。 最長(zhǎng)的暫停時(shí)間為721毫秒。 因此，讓我們以此為基準(zhǔn)：GC周期將吞吐量減少了總運(yùn)行時(shí)間的1.1％ 。 最壞情況下的延遲是721ms 。

下一位參賽者：CMS（ -XX：+ UseConcMarkSweepGC ）。 同樣，經(jīng)過30分鐘的測(cè)試，我們損失了不到19秒的GC時(shí)間。 在吞吐量方面，這與并行模式大致處于同一鄰域。 另一方面，延遲得到了顯著改善– 最壞情況下的延遲減少了10倍以上！ 現(xiàn)在，GC面臨的最大暫停時(shí)間僅為64毫秒 。

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

結(jié)論

與往常一樣，試圖將這樣的實(shí)驗(yàn)總結(jié)為一個(gè)結(jié)論是危險(xiǎn)的。 因此，如果您有時(shí)間和必要的技能–一定要繼續(xù)測(cè)量自己的環(huán)境，而不是采用一刀切的解決方案。

但是，如果我敢于做出這樣的結(jié)論，我會(huì)說CMS仍然是最好的“默認(rèn)”選項(xiàng)。 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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。