G1，CMS及PARALLEL GC的比較

這篇文章正好接上前一年咱們作的一次現實環境下不一樣GC算法性能比較的試驗。此次咱們仍然進行一樣的試驗，不過增長了對G1回收器的測試，而且在多個平臺進行測試。今年咱們測試的垃圾回收器有以下幾個：

• -XX:+UseParallelOldGC
• -XX:+UseConcMarkSweepGC
• -XX:+UseG1GC

運行環境

咱們使用現成的JIRA任務來運行這個測試。選擇它的緣由很是簡單——除去Minecraft（一款著名網遊），憤怒的小鳥，以及Eclipse不說， JIRA應該是最著名的Java應用程序了。而且和別的候選者相比，它更能表明咱們平常的業務處理流程——畢竟來講Java用得最多的地方仍是在服務端的Java企業級應用。

影響咱們決定的還有一個因素—— Atlassian的工程師們發佈了一個打包好的JIRA壓測腳本 。咱們能夠直接用它來進行咱們的基準測試。

咱們仔細的將最新版的JIRA6.1解壓，而後把它安裝到Mac OS X Mavericks上。最後直接使用默認的內存參數設置來運行這個測試程序。Atlassian團隊的傢伙已經幫咱們把參數也設置好了：

-Xms256m -Xmx768m -XX:MaxPermSize=256m

這個程序使用了JIRA的常見的幾種不一樣功能——建立任務，分配任務，解析任務，查找及發現任務，等等。總的運行時間是30分鐘。

咱們使用了三種不一樣的GC算法來運行這個測試——Parallel，CMS， 和G1。每次測試都從新啓動一個新的JVM實例，並事先把存儲恢復到一樣的狀態。一切準備就緒後咱們纔開始啓動壓測。

結果

每次測試咱們都經過-XX:+PrintGCTimeStamps -Xloggc:/tmp/gc.log -XX:+PrintGCDetails來收集GC日誌，最後使用GCViewer來分析裏面的數據。

彙總後的結果以下。注意測試結果的單位是毫秒。

年	Parallel	CMS	G1
Total GC pauses	20 930	18 870	62 000
Max GC pause	721	64	50

說明

首先來看Parallel GC (-XX:+UseParallelOldGC)。在這30分鐘的測試過程當中，並行收集器的GC大概暫停了有21秒。最長的一次花了721毫秒。咱們來以這個作爲基準：從總的運行時間來看，GC週期減小了1.1%的吞吐量。最長的延遲時間大概是721毫秒。

下一個：CMS（-XX:+UseConcMarkSweepGC）。在30分鐘的測試中，因爲GC而損失的時間是19秒。吞吐量和上一次的並行模式下的差很少。不過期延方面有了明顯的改善——最壞的狀況下的時延減小了10倍！如今最大的GC暫停時間只有64毫秒。

最後一次測試用的是最新最潮的GC算法——GC（-XX:+UseG1GC）。運行的是一樣的測試程序，不過結果的吞吐量則嚴重降低了。此次測試應用在GC上花費的時間超過了一分鐘。和CMS只有1%的開銷相比，此次的吞吐量降低了有3.5%。不過若是你不在意吞吐量而更在意時延的話——這方面它和前面表現最好的CMS相比還有20%的提高——G1回收器最長的暫停時間只有50ms。

結論

想經過這麼一次試驗來得出一個結論是很是危險的。若是你的時間充足又有相應的能力的話——你應該在本身的環境中具體狀況具體分析，而不是使用一刀切的方法。

不過若是說非要得出一個結論，我認爲說CMS仍然是最佳的默認選擇。G1的吞吐量實在是太差，和它所減小的那點時延相比並不划算。