垃圾收集器

上次說到了垃圾收集演算法，這次我們聊一下HotSpot的具體垃圾收集器的實現，以JDK1.7為例，其包含的可選垃圾收集器如下圖：

不同收集器之間的連線，代表它們可以搭配使用，收集器所屬的區域代表它們屬於新生代收集器還是老年代收集器，下面總結一下每個收集器的特點：

Serial 收集器

Serial 字面意思為串列，這與它的工作方式是有關係的，因為它是一個單線程收集器，他在新生代工作，採取的是複製演算法，在單CPU的機器上可以高效的完成收集工作，其對於運行在Client模式下的虛擬機是一個很好的選擇。

ParNew收集器

ParNew收集器其實就是Serial收集器的多線程版本，除了採用多線程進行垃圾收集之外，其餘行為包括控制參數、收集演算法、STW、對象分配法則、回收策略都與Serial收集器完全一樣。由於採用多線程ParNew通常是虛擬機運行在Server模式下的首選新生代收集器，ParNew收集器能與CMS收集器配合工作，他默認開啟的收集線程數與CPU的數目相同，可以使用-XX：ParallelGCThread
參數設施線程數量

Parallel Scavenge收集器

從名稱可以看出Parallel
Scavenge也是並行的多線程收集器，工作在新生代，採用複製演算法進行收集，那和ParNew相比它有什麼特別之處呢？與其他收集器的關注點不同，CMS等收集器的關注點是儘可能的縮短垃圾收集時用戶線程的停頓時間，而Parallel

Scavenge收集器的目標則是吞吐量，所謂吞吐量是指CPU用於運行用戶代碼的時間與CPU總消耗時間的比值。如果說實際應用場景，那麼CMS等停頓時間較短的收集器適合需要與用戶進行交互的程序，以獲得良好的響應速度，而Parallel
Scavenge收集器具有較高的吞吐量則可以高效的利用CPU時間，儘快完成運算任務，適合後台運算不需要太多交互的任務。

Parallel Scavenge收集器提供了兩個參數可以用於精確控制吞吐，分別是最大垃圾收集停頓時間：-XX:MaxGCPauseMillis
以及知己設置吞吐量大小的-XX:FCGCTimeRatio參數，另外還提供了一個自動調節的參數：-XX:PretenureSize

Serial Old收集器

它是Serial收集器的老年代版本，同樣是一個單線程收集器，使用標記-整理演算法

Parallel Old收集器

他是Parallel Scavenge 收集器的老年代版本，使用標記-整理演算法，配合PS收集器使用。

CMS收集器 Concurrent Mark Sweep

CMS是一種以獲取最短回收暫停時間為目標的收集器，從名稱可以看出CMS是基於標記-整理演算法實現的，它的運作過程比較複雜，整個過程分為4個步驟：

1. 初始標記 initial mark

   這個階段會掃描root對象直接關聯的可達對象。注意不會遞歸的追蹤下去，只是到達第一層而已。這個過程，會STW，但是時間很短。

2. 並發標記 concurrent mark

   這個階段是進行真正的GC Tracing，遞歸分析存活對象，無須STW

3. 重新標記 remark

   需要STW，因為並發標記階段，用戶程序繼續運行，所以重寫標記那些產生變化的對象。

4. 並發刪除 concurrent sweep

   無須STW，對分析出的死亡對象進行清理。

CMS收集器的缺點

1. 對CPU資源敏感

由於並行的特性，需要佔用cpu資源，影響用戶程序性能，CMS默認啟動的回收線程是（CPU數量 + 3）/ 4 當CPU數量小於4個時，CPU數量越少垃圾回收線程佔比越大。

1. 無法處理浮動垃圾

Floating Garbage，可能會出現Concurrent Mode Failure，而導致另一次Full
GC的產生，浮動垃圾是什麼，由於並發刪除階段用戶線程還在執行，自然還會產生新的垃圾，這部分垃圾在標記步驟之後，所以無法清理，只要等待下一次GC。由於並發的特性，CMS的不能像其他收集器那樣等到老年代幾乎完全被填滿再進行收集，需要預留一部分空間提供並發收集時的用戶程序使用，JDK1.5的默認設置是老年代使用了68%的空間後就會被激活，1.6為92%，這個比例可以通過參數

-XX:CMSInitiatingOccupancyFraction來調整，如果GC期間預留的內存空間無法滿足用戶程序要求，就會出現一次「Concurrent
Mode Failure」，這時會啟動後備預案，臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。

1. 內存碎片

由於CMS採用標記-刪除演算法，會產生大量的內存碎片，造成分配大對象時，雖然老年代存在不少剩餘空間，但找不到可用的內存空間，不得不提前觸發一次Full
GC，為了解決這個問題，CMS提供了一個-XX:UseCMSCompactAtFullCollection
開關參數，用於在CMS頂不住進行Full
GC時開啟內存碎片整理合併，由於整理過程無法並發，所以停頓時間不得不邊長，另外還有一個參數-XX:CMDSFullGCsBeforeCompaction，這個參數是用於設置執行多少次不壓縮的Full
GC後，再進行一次帶壓縮的Full GC，默認為0，表示每次都進行碎片整理。

G1 收集器

Garbage First 是最前沿的收集器之一，在JDK1.7 u4開始商用，它具有如下特點：

1.並發與並行 充分利用多CPU和多核的硬體優勢，來縮短STW停頓的時間

2.分代收集，且不需要其他收集器配合就可以獨立管理整個Java堆

3.整體上採用標記-整理演算法，內部不同Region之間採用複製演算法。

4.可預測的停頓，使用者可以指定消耗在垃圾回收上的時間。

比較特別的是G1收集器將整個Java對劃分為多個大小相等的獨立區域Region，雖然仍然保留新生代和老年代，但已經不再有明顯的物理界限，他們只是一部分Region的集合。G1會跟蹤各個Region里的垃圾堆積價值大小（回收所獲得的空間大小以及所需時間的經驗值），維護一個優先列表，每次根據允許的收集時間，優先回收價值最大的Region。

內存分配與回收策略

1. 對象優先在Eden分配

大多數情況下，對象在新生代Eden區中分配，當Eden沒有足夠空間時，將發生一次MinorGC，虛擬機提供了-XX:PrintGCDetails這個參數，在虛擬機發生垃圾收集時列印內存回收日誌，並在內存退出時輸出當前的內存各區域分配情況。（MinorGC又稱新生代GC，MajorGC/FullGC又稱老年代C）。

1. 大對象直接進入老年代

java虛擬機提供了一個-XX:PretenureSizeThreshold參數，設置直接在老年代分配的對象的大小，這樣可以避免在Eden和兩個Survivor區域之間發生大量內存複製。（這個參數只對Serial和ParNew收集器有效）

1. 長期存活對象將進入老年代

虛擬機為每個對象定義了一個年齡（Age）計數器，如果對象在Eden區域出生並經過第一次MinorGC後仍然存活，並且能被Survivor容納的話，將被移動到Survivor空間中，並且對象年齡設為1，對象在Survivor區域熬過一次MinorGC，年齡就加1，當年齡增加到一定程度（默認是15歲），就會被晉陞為老年代，這個閥值可以通過參數：-XX:MaxTenuringThreshold設置。

1. 動態對象年齡判定

為了更好的適應不同程序的內存情況，虛擬機並不是永遠的要求對象的年齡必須達到了MaxTenuringThreshold才能晉陞老年代，如果在Survivor空間中相同年齡的所有對象大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的對象就可以直接進入老年代。

1. 空間分配擔保

在發生MinorGC之前，虛擬機會先檢查老年代最大可用的連續空間是否大於新生代所有對象的空間，如果這個條件成立，那麼MinorGC就是安全的，如果不成立，則虛擬機會查看HandlePromotionFailure設置值是否允許擔保失敗，如果允許，那麼會繼續檢查老年代最大可用的連續空間是否大於歷次晉陞到老年代對象的平均大小，如果大於，將嘗試進行一次MinorGC，儘管這次MinorGC有風險；如果小於，或者HandlePromotionFailure設置不允許冒險，這是也要改為進行一次Full
GC。

更多IT精品課程，訪問中公優就業官網：http://xue.ujiuye.com

勤工儉學計劃」，給你一個真正0元學習IT技術的機會！

http://www.ujiuye.com/zt/qgjx/?wt.bd=lsh

找工作太難？不是你不行，我們來幫你！

http://www.ujiuye.com/zt/jyfc/?wt.bd=lsh

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！