1. 程式人生 > >GC回收器

GC回收器

一、說明:

concurrent:  併發, 多個執行緒協同做同一件事情(有狀態);

parallel:        並行, 多個執行緒各做各的事情(互相間無共享狀態);

二、GC回收器

Java堆記憶體被劃分為新生代和年老代,新生代主要使用複製和標記-清除垃圾回收演算法,年老代主要使用標記-整理垃圾回收演算法。

2.1、Serial

Serial是一個單執行緒的收集器,採用複製演算法。它只會使用一個CPU或一條執行緒去完成垃圾收集工作,在進行垃圾收集的同時,必須暫停其他所有的工作執行緒,直到垃圾收集結束。

優點:簡單高效,單個CPU環境來說,沒有執行緒互動的開銷,可以獲得最高的單執行緒垃圾收集效率

2.2、ParNew

ParNew是Serial的多執行緒版本,也使用複製演算法,除了使用多執行緒進行垃圾收集之外,其餘的行為和Serial收集器完全一樣,ParNew垃圾收集器在垃圾收集過程中同樣也要暫停所有其他的工作執行緒。

ParNew收集器預設開啟和CPU數目相同的執行緒數,可以通過-XX:ParallelGCThreads引數來限制垃圾收集器的執行緒數。

2.3、Parallel Scavenge

多執行緒回收器,也使用複製演算法,是吞吐量優先的垃圾收集器,它還提供一個引數:-XX:+UseAdaptiveSizePolicy,開啟之後就不需要手動指定新生代大小(-Xmn)、Eden與Survivor區的比例(-XX:SurvivorRation)、新生代晉升年老代物件年齡(-XX:PretenureSizeThreshold)等細節引數,虛擬機器會根據當前系統執行情況收集效能監控資訊,動態調整這些引數以達到最大吞吐量,這種方式稱為GC自適應調節策略

,自適應調節策略也是ParallelScavenge收集器與ParNew收集器的一個重要區別。

2.4、Serial Old

Serial Old是Serial垃圾收集器年老代版本,它同樣是個單執行緒的收集器,使用標記-整理演算法。其作用如下:

a、在JDK1.5之前版本中與新生代的Parallel Scavenge收集器搭配使用。

b、作為年老代中使用CMS收集器的後備垃圾收集方案。

新生代Serial與年老代Serial Old搭配垃圾收集過程圖:

新生代Parallel Scavenge/ParNew與年老代Serial Old搭配垃圾收集過程圖:

2.5、Parallel Old

Parallel Old是Parallel Scavenge的年老代版本,使用多執行緒的標記-整理演算法。

新生代Parallel Scavenge和年老代Parallel Old收集器搭配執行過程圖:

2.6、CMS(Concurrent mark sweep)

CMS是一種年老代垃圾收集器,其最主要目標是獲取最短垃圾回收停頓時間(可以為互動比較高的程式提高使用者體驗),與其他年老代使用標記-整理演算法不同,它使用多執行緒的標記-清除演算法。第一款真正意義上併發垃圾收集器,它第一次實現了讓垃圾收集執行緒和使用者執行緒同時工作。

CMS工作機制相比其他的垃圾收集器來說更復雜,整個過程分為以下4個階段:

a、初始標記:只是標記一下GC Roots能直接關聯的物件,速度很快,仍然需要暫停所有的工作執行緒。

b、併發標記:進行GC Roots跟蹤的過程,和使用者執行緒一起工作,不需要暫停工作執行緒。

c、重新標記:為了修正在併發標記期間,因使用者程式繼續執行而導致標記產生變動的那一部分物件的標記記錄,仍然需要暫停所有的工作執行緒。

d、併發清除:清除GC Roots不可達物件,和使用者執行緒一起工作,不需要暫停工作執行緒。

由於耗時最長的併發標記和併發清除過程中,垃圾收集執行緒可以和使用者現在一起併發工作,所以總體上來看CMS收集器的記憶體回收和使用者執行緒是一起併發地執行。

CMS收集器工作過程:


CMS收集器缺點:

a、CMS收集器對CPU資源非常敏感

其預設啟動的收集執行緒數=(CPU數量+3)/4,在使用者程式本來CPU負荷已經比較高的情況下,如果還要分出CPU資源用來執行垃圾收集器執行緒,會使得CPU負載加重。

b、CMS無法處理浮動垃圾(Floating Garbage),可能會導致Concurrent Mode Failure失敗而導致另一次Full GC

由於CMS收集器和使用者執行緒併發執行,因此在收集過程中不斷有新的垃圾產生,這些垃圾出現在標記過程之後,CMS無法在本次收集中處理掉它們,只好等待下一次GC時再將其清理掉,這些垃圾就稱為浮動垃圾。CMS垃圾收集器不能像其他垃圾收集器那樣等待年老代機會完全被填滿之後再進行收集,需要預留一部分空間供併發收集時的使用,可以通過引數-XX:CMSInitiatingOccupancyFraction來設定年老代空間達到多少的百分比時觸發CMS進行垃圾收集,預設是68%。如果在CMS執行期間,預留的記憶體無法滿足程式需要,就會出現一次ConcurrentMode Failure失敗,此時虛擬機器將啟動預備方案,使用Serial Old收集器重新進行年老代垃圾回收。

c、CMS收集器是基於標記-清除演算法,因此不可避免會產生大量不連續的記憶體碎片

如果無法找到一塊足夠大的連續記憶體存放物件時,將會觸發因此Full GC。CMS提供一個開關引數-XX:+UseCMSCompactAtFullCollection,用於指定在Full GC之後進行記憶體整理,記憶體整理會使得垃圾收集停頓時間變長,CMS提供了另外一個引數-XX:CMSFullGCsBeforeCompaction,用於設定在執行多少次不壓縮的Full GC之後,跟著再來一次記憶體整理。

案例剖析:

1. promotion failed – concurrent mode failure

Minor GC後, 新生代救助空間容納不了剩餘物件,將要放入老年帶,老年帶有碎片或者不能容納這些物件,就產生了concurrent mode failure, 然後進行stop-the-world的Serial Old收集器(CMS就沒什麼意義了)。

解決辦法:-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=5 或者 調大新生代或者救助空間

2. concurrent mode failure

CMS是和業務執行緒併發執行的,在執行CMS的過程中有業務物件需要在老年帶直接分配,例如大物件,但是老年帶沒有足夠的空間來分配,所以導致concurrent mode failure, 然後需要進行stop-the-world的Serial Old收集器(CMS就沒什麼意義了)。

解決辦法:+XX:CMSInitiatingOccupancyFraction,調大老年帶的空間,+XX:CMSMaxAbortablePrecleanTime

總結一句話:使用標記整理清除碎片和提早進行CMS操作。

2.7、G1

Garbage first垃圾收集器是目前垃圾收集器理論發展的最前沿成果,相比與CMS收集器,G1收集器兩個最突出的改進是:

a、基於標記-整理演算法,不產生記憶體碎片。

b、可以非常精確控制停頓時間,在不犧牲吞吐量前提下,實現低停頓垃圾回收。

G1收集器避免全區域垃圾收集,它把堆記憶體劃分為大小固定的幾個獨立區域,並且跟蹤這些區域的垃圾收集進度,同時在後臺維護一個優先順序列表,每次根據所允許的收集時間,優先回收垃圾最多的區域。區域劃分和優先順序區域回收機制,確保G1收集器可以在有限時間獲得最高的垃圾收集效率。

 

三、常用GC組合

Serial
ParNew + CMS(+ 後備 Serial Old)
ParallelYoung + ParallelOld
G1GC

 

Ref:

https://my.oschina.net/u/1464779/blog/220633

https://my.oschina.net/hosee/blog/674181

https://my.oschina.net/hosee/blog/644618#OSC_h2_6