Java虛擬機-垃圾收集器

垃圾收集器能夠分爲新生代收集器和老年代收集器；

新生代收集器：

一、  Serial收集器

Serial收集器是單線程收集器，採用複製算法，並行收集器，執行的時候須要用戶線程暫停。

虛擬機運行在Client模式下的默認新生代收集器。

二、  ParNew收集器

ParNew收集器是多線程收集器，採用複製算法，並行收集器，執行的時候須要用戶線程暫停。

除了Serial收集器能夠和CMS收集器搭配使用以外，就是ParNew收集器；

三、  Parallel Scavenge收集器

Parallel Scavenge收集器是多線程收集器，採用複製算法，並行收集器，執行的時候須要用戶線程暫停。

此收集器主要注重的是可控制的吞吐量；

吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集的時間)

老年代收集器：

一、  Serial Old收集器

Serial Old收集器是單線程收集器，採用標記-整理算法，並行收集器，執行的時候須要用戶線程暫停。

Sweep清理和Compact壓縮：

清理就是把廢棄的對象幹掉，只留下倖存的對象；

壓縮就是將移動對象，將空間填滿保證內存分爲2塊，一塊是全是對象，一塊空閒

二、  Parallel Old收集器

Parallel Old收集器是多線程收集器，採用標記-整理算法，並行收集器，執行的時候須要用戶線程暫停。

JDK1.6纔開始提供此收集器。

Summary彙總和Compact壓縮：

匯老是將倖存的對象複製到預先準備的區域

三、  CMS收集器

CMS收集器是多線程收集器，採用標記-清除算法，併發收集器，執行的時候能夠和用戶線程一塊兒，停頓時間小；

分爲四個過程：初始標記、併發標記、從新標記和併發清理

初始標記和從新標記是須要用戶線程暫停；

併發標記和併發清理不須要用戶線程暫停；

初始標記：標記GC Roots能關聯到的對象，停頓時間很短。

併發標記：執行GC Roots查找引用的過程，不須要用戶線程停頓。

從新標記：在初始化標記和併發標記期間，有標記變更的那部分仍然須要標記，因此加上這一部分標記過程，停頓時間比並發標記小，可是比初始標記稍微長。

併發清除：在完成標記以後，就開始併發清除，不須要用戶線程停頓。

在CMS清理過程當中，只有初始標記和從新標記須要停頓用戶線程，併發標記和併發清除不須要用戶線程停頓，所以效率很高，很適合高交互的場合。

CMS的缺點：

1：對CPU資源比較敏感

它須要消耗額外的CPU和內存資源，在CPU和內存資源緊張的時候，CPU較少時，會加劇系統負擔；CMS默認啓動線程數量：（CPU數量+3）/4

2：CMS收集器沒法處理浮動垃圾

CMS收集器在併發收集過程當中，用戶線程仍然在執行，仍然會產生內存垃圾，因此可能產生浮動垃圾，本次沒法清理就只能等待下一次Full GC，由於GC期間須要預留足夠內存給用戶線程使用，因此使用CMS收集器並非年老代滿了纔會執行Full GC，而是在使用了一大半（默認68%，也就是2/3，使用-XX:CMSInitiatingOccupancyFraction來設置）的時候就要進行Full GC，若是用戶線程消耗內存不是特別大，能夠適當調高參數來下降GC次數，以此提升性能。若是預留的用戶線程內存不夠，則會觸發ConcurrentModeFailure，此時將觸發備用方案：使用Serial Old收集器來手機，可是這樣停頓時間就會長了，所以-XX:CMSInitiatingOccupancyFraction不能設置的過大。

3：CMS採用標記-清除算法，會產生內存碎片

其餘收集器：

一、  G1收集器

G1是一款面向服務端應用的垃圾收集器，在JDK1.7中出現。

G1是採用標記-整理算法。

分爲4個步驟：初始標記、併發標記、最終標記、篩選回收；

1：初始標記

標記一下GC Roots能直接關聯到的對象，而且修改TAMS 的值，讓下一階段用戶程序併發運行時可以正確可用的Region中建立新對象。此操做須要停頓線程，耗時很短。

2：併發標記

從GC Roots開始對堆中對象進行可達性分析，找出存活的對象。耗時比較長，能夠與用戶線程併發執行；

3：最終標記

爲了修正併發標記期間，因用戶線程繼續執行而致使標記產生變更的那一部分標記記錄；

虛擬機將這段時間對象變化記錄在線程Remembered Set Logs裏面。

最終標記須要將Remembered Set Logs裏面的數據合併到Remembered Set中。

此操做須要停頓線程，可是能夠並行執行。

4：篩選回收

首先將各個Region的回收價值和成本進行排序，根據用戶所指望的GC停頓時間來制定回收計劃，回收一部分Region，時間是用戶控制的，並且停頓用戶線程將大幅度提升收集效率。

G1收集器的優勢：

1：並行與併發

G1可以充分利用多CPU、多核環境下的硬件優點，使用多個CPU來縮短停頓的時間，部分其餘收集器是須要停頓Java線程執行GC動做，G1收集器仍然能夠經過併發的方式讓Java線程繼續執行；

2：分代收集

G1雖然能夠不須要其餘收集器配合就能獨立管理整個GC堆，可是它可以採用不一樣的方式處理新建立對象和已經存活了一段時間、熬過屢次GC的舊對象以得到更好的手機效果。

3：空間整合

G1從總體上來看是標記-整理算法實現的收集器，從局部上看是基於「複製算法」實現，可是不管如何這兩種算法都意味着G1運做期間不會產生內存空間碎片，收集後可以提供規整的可用內存。

這種特性有利於程序的長時間運行，分配大對象時就不會由於沒法找到連續內存空間而提早觸發下一次Full GC。

4：可預測的停頓

G1除了追求低停頓外，還能創建可預測的停頓時間模型，能讓使用者明確指定在一個長度爲毫秒的時間片斷內，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已是實時Java（RTSJ）的垃圾收集器的特徵。

 

G1收集器將Java堆劃分爲多個大小相等的獨立區域Region。

G1之因此可以創建可預測的停頓時間模型，主要是它有計劃得避免了在整個Java堆中進行全區域的垃圾收集。

G1跟蹤各個Region裏面的垃圾堆積的價值大小，在後臺維護一個優先列表，每次根據容許收集時間，優先回收價值最大的Region。

這種使用Region劃分空間以及優先級的區域回收方式，保證了G1在有限的時間內能夠獲取儘量高的收集效率。