6.HotSpot垃圾收集器

HotSpot JVM收集器

              上面有7中收集器，分為兩塊，上面為新生代收集器，下面是老年代收集器。如果兩個收集器之間存在連線，就說明它們可以搭配使用。

並發和並行

　　先解釋下什么是垃圾收集器的上下文語境中的並行和並發：

　　並行（Parallel）：指多條垃圾收集器線程並行工作，但此時用戶線程仍然處於等待。

　　並發（Concurrent）：指用戶線程與垃圾收集器線程同時執行（但不一定是並行的，可能會交替執行），用戶程序在繼續運行，而垃圾收集器程序運行於另一個CPU之上。

Serial(串行GC)收集器

　　Serial收集器是一個新生代收集器，單線程執行，使用復制算法。它在進行垃圾收集時，它不僅只會使用一個CPU或者一條收集線程去完成垃圾收集作，而且必須暫停其他所有的工作線程(用戶線程),直到它收集完成。

　　　　　　　　

　　　　　　　　　　　　　　 Serial/Serial Old收集器運行示意圖（表示Serial和Serial Old搭配使用）

　　是Jvm client模式下默認的新生代收集器。對於限定單個CPU的環境來說，簡單高效，Serial收集器由於沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率，因此是運行在Client模式下的虛擬機的不錯選擇（比如桌面應用場景）。

ParNew(並行GC)收集器

ParNew收集器其實就是serial收集器的多線程版本，使用復制算法。除了使用多條線程進行垃圾收集之外，其余行為與Serial收集器一樣。

　　　　　　　　　　

　　　　　　　　　　　　　　　 ParNew/Serial Old收集器運行示意圖（表示ParNew和Serial Old搭配使用）

　　是運行在 Service模式下虛擬機中首選的 新生代收集器，其中一個與性能無關的原因就是 除了Serial收集器外，目前只有ParNew收集器能與CMS收集器配合工作。

　　PreNew收集器在單CPU環境中絕對沒有Serial的效果好，由於存在線程交互的開銷，該收集器在超線程技術實現的雙CPU中都不能一定超過Serial收集器。默認開啟的垃圾收集器線程數就是CPU數量，可通過-XX：parallelGCThreads參數來限制收集器線程數

Parallel Scavenge(並行回收GC)收集器

　　Parallel Scavenge收集器也是一個新生代收集器，它也是使用復制算法的收集器，又是並行多線程收集器。parallel Scavenge收集器的特點是它的關注點與其他收集器不同，CMS等收集器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間，而parallel Scavenge收集器的目標則是達到一個可控制的吞吐量。吞吐量= 程序運行時間/(程序運行時間 + 垃圾收集時間)，虛擬機總共運行了100分鍾。其中垃圾收集花掉1分鍾，那吞吐量就是99%。

　　　　　　　　　　

　　　　　　Parallel Scavenge/Parallel Old收集器運行示意圖（表示Parallel Scavenge和Parallel Old搭配使用）

　　短停頓時間適合和用戶交互的程序，體驗好。高吞吐量適合高效利用CPU，主要用於后台運算不需要太多交互。

　　提供了兩個參數來精確控制吞吐量：1.最大垃圾收集器停頓時間（-XX：MaxGCPauseMillis    大於0的毫秒數，停頓時間小了就要犧牲相應的吞吐量和新生代空間），2.設置吞吐量大小（-XX：GCTimeRatio    大於0小於100的整數，默認99，也就是允許最大1%的垃圾回收時間）。

　　還有一個參數表示自適應調節策略（GC Ergonomics）（-XX：UseAdaptiveSizePolicy）。就不用手動設置新生代大小（-Xmn）、Eden和Survivor區的比例（-XX：SurvivorRatio）今生老年代對象大小（-XX：PretenureSizeThreshold），會根據當前系統的運行情況手機監控信息，動態調整停頓時間和吞吐量大小。也是其與PreNew收集器的一個重要區別，也是其無法與CMS收集器搭配使用的原因（CMS收集器盡可能地縮短垃圾收集時用戶線程的停頓時間，以提升交互體驗）。

Serial Old(串行GC)收集器

Serial Old是Serial收集器的老年代版本，它同樣使用一個單線程執行收集，使用“標記-整理”算法。主要使用在Client模式下的虛擬機。

　　　　　　　　

　　　　　　　　　　　　　　 Serial/Serial Old收集器運行示意圖（表示Serial和Serial Old搭配使用）

　　如果在Service模式下使用：1.一種是在JDK1.5以及之前的版本中與Parallel Scavenge收集器搭配使用，因為那時還沒有Parallel  Old老年代收集器搭配；2.另一種就是作為CMS收集器的后備預案，在並發收集發生Concurrent Model Failure時使用。

Parallel Old(並行GC)收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法，JDK1.6才提供。

　　由於之前有一個Parallel Scavenge新生代收集器，，但是卻無老年代收集器與之完美結合，只能采用Serial Old老年代收集器，但是由於Serial Old收集器在服務端應用性能上低下（畢竟單線程，多CPU浪費了），其吞吐量反而不一定有PreNew+CMS組合。

　　　　　　　　

　　　　　　Parallel Scavenge/Parallel Old收集器運行示意圖（表示Parallel Scavenge和Parallel Old搭配使用）

CMS(並發GC)收集器

　　CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器。CMS收集器是HotSpot虛擬機中的一款真正意義上的並發收集器，第一次實現了讓垃圾回收線程和用戶線程（基本上）同時工作。用CMS收集老年代的時候，新生代只能選擇Serial或者ParNew收集器。

　　CMS收集器是基於“標記-清除”算法實現的，整個收集過程大致分為4個步驟：

①.初始標記(CMS initial mark)

②.並發標記(CMS concurrenr mark)

③.重新標記(CMS remark)

④.並發清除(CMS concurrent sweep)

     其中 初始標記、重新標記這兩個步驟任然需要停頓其他用戶線程（Stop The World）。 初始標記僅僅只是標記出GC ROOTS能 直接關聯到的對象，速度很快， 並發標記階段是進行GC ROOTS 根搜索算法階段，會判定對象是否存活。而重新標記階段則是為了 修正並發標記期間，因用戶程序繼續運行而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間會被初始標記階段稍長，但比並發標記階段要短。

     由於整個過程中耗時最長的並發標記和並發清除過程中，收集器線程都可以與用戶線程一起工作，所以整體來說，CMS收集器的內存回收過程是與用戶線程一起並發執行的。

　　　　　　

　　　　　　　　　　　　　　　　CMS收集器運行示意圖

CMS收集器的優點： 並發收集、低停頓，但是CMS還遠遠達不到完美，器主要有三個顯著缺點：

　　1.CMS收集器 對CPU資源非常敏感。在並發（並發標記、並發清除）階段，雖然不會導致用戶線程停頓，但是會占用CPU資源而導致應用程序變慢，總吞吐量下降。 CMS默認啟動的回收線程數是：(CPU數量+3) / 4。 收集器線程所占用的CPU數量為：（CPU+3）/4=0.25+3/（4*CPU）。因此這時垃圾收集器始終不會占用少於25%的CPU，因此當進行並發階段時，雖然用戶線程可以跑，但是很緩慢，特別是雙核CPU的時候，已經占用了5/8的CPU，吞吐量會很低。為了解決這種情況，產生了“ 增量式並發收集器”（Incremental Concurrent Mark Sweep/i-CMS）。就是采用搶占方式來模擬多任務機制，就是在並發（並發標記、並發清除）階段，讓GC線程、用戶線程交替執行，盡量減少GC線程獨占CPU，這樣垃圾收集過程更長，但是對用戶程序影響小一些。實際上i-CMS效果很一般，目前已經被聲明為“deprecated”。

　　2.CMS收集器 無法處理浮動垃圾，可能出現“Concurrent Mode Failure“，失敗后而導致另一次Full  GC的產生。由於CMS並發清理階段用戶線程還在運行，伴隨程序的運行自熱會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之后，CMS無法在本次收集中處理它們，只好留待下一次GC時將其清理掉。這一部分垃圾稱為“ 浮動垃圾”。也是由於在垃圾收集階段用戶線程還需要運行，即需要預留足夠的內存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集， 需要預留一部分內存空間提供並發收集時的程序運作使用。在默認設置下，CMS收集器在老年代使用了 68%的空間時就會被激活，也可以通過參數-XX:CMSInitiatingOccupancyFraction的值來 提高觸發百分比，以降低內存回收次數提高性能。JDK1.6中，CMS收集器的啟動閾值已經提升到92%。要是CMS運行期間預留的內存無法滿足程序其他線程需要，就會出現“Concurrent Mode Failure”失敗，這時候虛擬機將啟動后備預案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置的過高將會很容易導致“Concurrent Mode Failure”失敗，性能反而降低。

　　3.最后一個缺點，CMS是基於“標記-清除”算法實現的收集器，使用 “標記-清除”算法收集后，會產生大量碎片。空間碎片太多時，將會給對象分配帶來很多麻煩，比如說 大對象，內存空間找不到連續的空間來分配不得不提前觸發一次Full  GC。為了解決這個問題，CMS收集器提供了一個-XX:UseCMSCompactAtFullCollection開關參數，用於在Full  GC之后增加一個內存碎片的合並整理過程，但是內存整理過程是無法並發的，因此解決了空間碎片問題，卻使停頓時間變長。還可通過-XX:CMSFullGCBeforeCompaction參數設置執行多少次不壓縮的Full  GC之后，跟着來一次碎片整理過程（默認值是0，表示每次進入Full GC時都進行碎片整理）。

G1收集器

　　G1(Garbage First)收集器是JDK1.7提供的一個新的面向服務端應用的垃圾收集器，其目標就是替換掉JDK1.5發布的CMS收集器。其優點有：

　　1.並發與並行：G1能充分利用多CPU、多核環境下的硬件優勢，使用多個CPU（CPU或CPU核心）來縮短停頓（Stop The World）時間。

　　2.分代收集：G1不需要與其他收集器配合就能獨立管理整個GC堆，但他能夠采用不同方式去處理新建對象和已經存活了一段時間、熬過多次GC的老年代對象以獲取更好收集效果。

　　3.空間整合：從整體來看是基於“標記-整理”算法實現，從局部（兩個Region之間）來看是基於“復制”算法實現的，但是都意味着G1運行期間不會產生內存碎片空間，更健康，遇到大對象時，不會因為沒有連續空間而進行下一次GC，甚至一次Full GC。

　　4.可預測的停頓：降低停頓是G1和CMS共同關注點，但G1除了追求低停頓，還能建立可預測的停頓模型，可以明確地指定在一個長度為M的時間片內，消耗在垃圾收集的時間不超過N毫秒

　　5.跨代特性：之前的收集器進行收集的范圍都是整個新生代或老年代，而G1擴展到整個Java堆(包括新生代，老年代)。

那么是怎么實現的呢？

　　1.如何實現新生代和老年代全范圍收集：其實它的Java堆布局就不同於其余收集器，它將整個Java堆划分為多個大小相等的獨立區域（Region），仍然保留新生代和老年代的概念，可是不是物理隔離的，都是一部分Region（不需要連續）的集合。

　　2.如何建立可預測的停頓時間模型：是因為有了獨立區域Region的存在，就避免在Java堆中進行全區域的垃圾收集，G1跟蹤各個Region里面的垃圾堆積的價值大小（回收可以獲得的空間大小和回收所需要的時間的經驗值），后台維護一個優先隊列，根據每次允許的收集時間，優先回收價值最大的Region（Garbage-First理念）。因此使用Region划分內存空間以及有優先級的區域回收方式，保證了有限時間獲得盡可能高的收集效率。

　　3.如何保證垃圾回收真的在Region區域進行而不會擴散到全局：由於Region並不是孤立的，一個Region的對象可以被整個Java堆的任意其余Region的對象所引用，在做可達性判定確定對象是否存活時，仍然會關聯到Java堆的任意對象，G1中這種情況特別明顯。而以前在別的分代收集里面，新生代規模要比老年代小許多，新生代收集也頻繁得多，也會涉及到掃描新生代時也會掃描老年代的情況，相反亦然。解決：G1收集器Region之間的對象引用以及新生代和老年代之間的對象引用，虛擬機都是使用Remembered Set來避免全堆掃描。G1中每個Region都有一個與之對應的Remembered Set,虛擬機發現程序在對Reference類型的數據進行寫操作時，會產生一個Write Barrier暫時中斷寫操作，檢查Reference引用的對象是否處於不同的Region之中(分代的例子中就檢查是否老年代對象引用了新生代的對象)，如果是則通過CardTable把相關引用信息記錄到被引用對象所屬的Region的Remembered Set之中，當進行內存回收時，在GC根節點的枚舉范圍中加入Remembered Set即可避免全堆掃描。

忽略Remembered Set的維護，G1的運行步驟可簡單描述為：

①.初始標記(Initial Marking)

②.並發標記(Concurrenr Marking)

③.最終標記(Final Marking)

④.篩選回收(Live Data Counting And Evacution)

1.初始標記：初始標記僅僅標記GC Roots能直接關聯到的對象，並且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶程序並發運行時，能在正確可用的Region中創建新的對象。這階段需要停頓線程，不可並行執行，但是時間很短。

2.並發標記：此階段是從GC Roots開始對堆中對象進行可達性分析，找出存活對象，此階段時間較長可與用戶程序並發執行。

3.最終標記：此階段是為了修正在並發標記期間因為用戶線程繼續運行而導致標記產生變動的那一份標記記錄，虛擬機將這段時間對象變化記錄在線程Remembered Set Logs里面，最終標記階段需要把Remembered Set Logs的數據合並到Remembered Set中，這段時間需要停頓線程，但是可並行執行。

4.篩選回收：對各個Region的回收價值和成本進行排序，根據用戶期望的GC停頓時間來制定回收計划。

　　如果現有的垃圾收集器沒有出現任何問題，沒有任何理由去選擇G1，如果應用追求低停頓，G1可選擇，如果追求吞吐量，和Parallel Scavenge/Parallel Old組合相比G1並沒有特別的優勢。

垃圾收集器參數總結

-XX:+<option> 啟用選項

-XX:-<option> 不啟用選項

-XX:<option>=<number> 

-XX:<option>=<string>

參數	描述
-XX:+UseSerialGC	Jvm運行在Client模式下的默認值，打開此開關后，使用Serial + Serial Old的收集器組合進行內存回收
-XX:+UseParNewGC	打開此開關后，使用ParNew + Serial Old的收集器進行垃圾回收
-XX:+UseConcMarkSweepGC	使用ParNew + CMS +  Serial Old的收集器組合進行內存回收，Serial Old作為CMS出現“Concurrent Mode Failure”失敗后的后備收集器使用。
-XX:+UseParallelGC	Jvm運行在Server模式下的默認值，打開此開關后，使用Parallel Scavenge +  Serial Old的收集器組合進行回收
-XX:+UseParallelOldGC	使用Parallel Scavenge +  Parallel Old的收集器組合進行回收
-XX:SurvivorRatio	新生代中Eden區域與Survivor區域的容量比值，默認為8，代表Eden:Subrvivor = 8:1
-XX:PretenureSizeThreshold	直接晉升到老年代對象的大小，設置這個參數后，大於這個參數的對象將直接在老年代分配
-XX:MaxTenuringThreshold	晉升到老年代的對象年齡，每次Minor GC之后，年齡就加1，當超過這個參數的值時進入老年代
-XX:UseAdaptiveSizePolicy	動態調整java堆中各個區域的大小以及進入老年代的年齡
-XX:+HandlePromotionFailure	是否允許新生代收集擔保，進行一次minor gc后, 另一塊Survivor空間不足時，將直接會在老年代中保留
-XX:ParallelGCThreads	設置並行GC進行內存回收的線程數
-XX:GCTimeRatio	GC時間占總時間的比列，默認值為99，即允許1%的GC時間，僅在使用Parallel Scavenge 收集器時有效
-XX:MaxGCPauseMillis	設置GC的最大停頓時間，在Parallel Scavenge 收集器下有效
-XX:CMSInitiatingOccupancyFraction	設置CMS收集器在老年代空間被使用多少后出發垃圾收集，默認值為68%，僅在CMS收集器時有效，-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSCompactAtFullCollection	由於CMS收集器會產生碎片，此參數設置在垃圾收集器后是否需要一次內存碎片整理過程，僅在CMS收集器時有效
-XX:+CMSFullGCBeforeCompaction	設置CMS收集器在進行若干次垃圾收集后再進行一次內存碎片整理過程，通常與UseCMSCompactAtFullCollection參數一起使用
-XX:+UseFastAccessorMethods	原始類型優化
-XX:+DisableExplicitGC	是否關閉手動System.gc
-XX:+CMSParallelRemarkEnabled	降低標記停頓
-XX:LargePageSizeInBytes	內存頁的大小不可設置過大，會影響Perm的大小，-XX:LargePageSizeInBytes=128m

 

Client、Server模式默認GC

	新生代GC方式	老年代和持久代GC方式
Client	Serial 串行GC	Serial Old 串行GC
Server	Parallel Scavenge  並行回收GC	Parallel Old 並行GC

Sun/Oracle JDK GC組合方式

	新生代GC方式	老年代和持久代GC方式
-XX:+UseSerialGC	Serial 串行GC	Serial Old 串行GC
-XX:+UseParallelGC	Parallel Scavenge  並行回收GC	Serial Old  並行GC
-XX:+UseConcMarkSweepGC	ParNew 並行GC	CMS 並發GC 當出現“Concurrent Mode Failure”時 采用Serial Old 串行GC
-XX:+UseParNewGC	ParNew 並行GC	Serial Old 串行GC
-XX:+UseParallelOldGC	Parallel Scavenge  並行回收GC	Parallel Old 並行GC
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	Serial 串行GC	CMS 並發GC  當出現“Concurrent Mode Failure”時 采用Serial Old 串行GC