JVM學習筆記之二 -- 垃圾回收器

    上一篇博文記錄了gc的各類算法，這篇博文記錄HotSpot中的幾種垃圾回收器。垃圾回收器是不一樣虛擬機對算法思想的實現。

    這張圖上面三個是新生代回收器、下面三個是老年代收集器。連線表示二者能夠配合使用，例如在虛擬機中能夠新生代使用Serial，老年代使用CMS。下面會介紹各類回收器的特性、原理和使用場景。收集器並無好壞之分，只有是否適合應用的場景。

1、新生代收集器

一、Serial

    顧名思義，這個收集器是「連續」的（單個GC線程）。意味着新生代執行gc時全部正常的工做線程是掛起狀態。Serial是最基礎的收集器。隨着虛擬機的發展出現了後面的收集器，但也有其優點。簡單高效，對於單核環境，沒有線程交互的開銷，而且適合運行在Client模式下的虛擬機。java -client, java -server能夠控制jvm模式。

二、ParNew

    ParNew其實就是Serial的多線程版本，除了使用多線程垃圾收集器以外（多個GC線程），其他行爲包括控制參數、收集算法、STW、對象分配規則、手機策略都與Serial相同。ParNew是server模式虛擬機首選的收集器，由於目前只有它能與CMS配合使用。ParNew適合在多核的服務器上使用。

三、Parallel Scavenge（PS）

    字面意思是「並行清理」，如圖可知PS也是新生代收集器、多線程、也使用了複製算法。PS的關注點是吞吐量和自適應。這是與前面收集器不一樣的。

    在這裏吞吐量被定義爲cpu用於運行用戶代碼的時間與cpu總時間之比。首先我想簡單說一下我對吞吐量的理解。吞吐量的定義是單位時間傳輸、處理的字節數或其餘單位。吞吐量大不必定意味着性能好或可用率高。對於gc來講cpu的吞吐量高意味着STW的時間會更長。對於要求響應速度的系統，若是有1分鐘沒法提供服務，是徹底不合理的。選擇吞吐量小但響應速度快的，多是更好的方案。二者的區別是，後者多是頓卡，但能夠提供服務，前者是在某段時間內沒法提供服務，但其餘時間正常。前面可能會得出吞吐量大性能差這個結論，其實否則，吞吐量即效率，能響應更多的請求。

    因此結論是：停頓時間越短越適合與用戶交互的程序，可以提高用戶體驗，而高吞吐量則能夠高效利用cpu時間，儘快完成運算任務，主要適合後臺運算而無需交互的任務。

    PS提供了兩個參數用於精確控制吞吐量：最大停頓時間-XX:MaxGCPauseMillis以及吞吐量大小-XX:GCTimeRatio。GC的停頓時間縮短是犧牲了吞吐量和新生代空間，收集300M和500M新生代，確定是前者快，但觸發的頻率高，假設後者是10s收集一次，每次100ms，前者是5s收集一次，每次50ms。收集速度加快，但效率變低了。

    PS收集器還有一個參數-XX:+UseAdaptiveSizePolicy。字面意思是「使用自適應的大小」，他的做用也是如此。當參數打開，就不須要指定新生代的小小、Eden和Survivor的比例等細節參數，虛擬機會根據當前系統運行狀況收集性能監控信息，動態調整參數，根絕前面兩個參數定義的最大停頓時間和吞吐率提供最合適的停頓時間或最大的吞吐量。

2、老年代收集器

一、Serial Old

    單線程老年代收集器，使用標記-整理算法。能夠應用在client模式下的虛擬機。若是是server模式，1.能夠跟PS配合使用 2.做爲CMS收集器的後備方案，在併發收集產生Concurrent Mode Failure時使用，也是二者連線的緣由。

2.Parallel Old

    多線程老年代收集器，一樣適用標記-整理算法。在Parallel Old出現以前，新生代的PS只能與Serial Old配合使用。尷尬的是，這種組合並不能體現出PS在吞吐量上的優點。在多核環境中其綜合性能不如ParNew+CMS。Parallel Old與Parallel Scavenge的組合適合應用於注重吞吐量和cpu資源敏感的場景中。這裏還須要再次說明，以上不論是單線程仍是多線程都會形成STW，全部工做線程都是掛起狀態。

3.CMS

    Concurrent Mark Sweep 是一種以獲取最短回收時間爲目標的收集器。Mark Sweep -> 標記-清除算法，整個過程分爲4步

• 初始標記
• 併發標記
• 從新標記
• 併發清除

    初始標記和從新標記任然須要STW。初始標記僅標記GC Root直接關聯的對象，速度快，單線程。併發標記進行GC Roots Tracing的過程。從新標記是爲了標記併發標記期間發生變化的對象，多線程。

    因爲時間最長的併發標記、併發清除都是與工做線程並行的，且其他兩個過程STW的時間相比並發階段要遠遠小於，因此整體上來講CMS的清除過程是與用戶線程併發的。

    制約CMS的條件也有不少：

1. 由於與用戶工做線程併發，毫無疑問會下降系統的併發量。CMS默認使用(cpu數量+3)/4個線程，意味着至少25%的cpu資源是用於gc的。
2. 因爲在清理過程當中還會繼續產生新的「垃圾」，這些垃圾只能留到下次清理，這些垃圾成爲「浮動垃圾」。所以CMS不會在老年代快用完時觸發，須要留一部分空間給「浮動垃圾」。虛擬機中能夠經過-XX:CMSInitiatingOccupancyFraction控制空間大小。若是參數設置太高，預留空間少，則容易出現老年代沒法知足需求的狀況，此時就會出現一次Concurrent Mode Failure。還記得前面說的Serial Old能夠配合CMS使用嗎，此時就會啓動這種後備方案。這樣停頓時間就很長了。
3. CMS使用標記-清除算法，無疑會增長內存碎片。我猜想不使用標記-整理算法的緣由是儘可能縮短STW。若是沒有足夠的空間分配大對象就會提早觸發一次Full GC。CMS提供了-XX:+UseCMSCompactAtFullCollection的開關參數，用於沒有足夠空間的狀況下是否作內存碎片整理的操做。默認開啓。還提供了另一個參數-XX:CMSFullGCsBeforeCompaction，用於設置執行多少次Full GC後執行一次壓縮整理操做。默認是0。這點其實很尷尬，收集操做很難作到兩全，就像cap理論，保證一致性就會影響可用性，保證可用性就要犧牲一致性。

 

    說了這麼多都是紙上談兵，但在上一篇博文中也說明過了，必然會有不少理論上的知識。至於收集器是如何標記、如何清除內存、如何整理等等，也許做爲一個初學者或應用系統工程師會很難接觸到，做爲初學者的我尚未那麼深的理解。可是若是把以上只是都掌握，對於運維本身開發的系統是頗有幫助的。

ps：上面又是隻說了GC沒說是Young GC 仍是 Full GC，請按不一樣年代的收集器理解就好。