http://blog.jobbole.com/109170/#comment-159599
本文首先簡單介紹了垃圾收集的常見方式，然后再分析了G1收集器的收集原理，相比其他垃圾收集器的優(yōu)勢，最后給出了一些調(diào)優(yōu)實踐。
一，什么是垃圾回收
首先，在了解G1之前，我們需要清楚的知道，垃圾回收是什么？簡單的說垃圾回收就是回收內(nèi)存中不再使用的對象。
垃圾回收的基本步驟
回收的步驟有2步：
- 查找內(nèi)存中不再使用的對象
- 釋放這些對象占用的內(nèi)存
1,查找內(nèi)存中不再使用的對象
那么問題來了，如何判斷哪些對象不再被使用呢？我們也有2個方法：
- 引用計數(shù)法
引用計數(shù)法就是如果一個對象沒有被任何引用指向，則可視之為垃圾。這種方法的缺點就是不能檢測到環(huán)的存在。
2.根搜索算法
根搜索算法的基本思路就是通過一系列名為”GC Roots”的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所走過的路徑稱為引用鏈(Reference Chain)，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。
現(xiàn)在我們已經(jīng)知道如何找出垃圾對象了，如何把這些對象清理掉呢？
2. 釋放這些對象占用的內(nèi)存
常見的方式有復制或者直接清理，但是直接清理會存在內(nèi)存碎片，于是就會產(chǎn)生了清理再壓縮的方式。
總得來說就產(chǎn)生了三種類型的回收算法。
1.標記-復制
它將可用內(nèi)存容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊用完之后，就將還存活的對象復制到另外一塊上面，然后在把已使用過的內(nèi)存空間一次理掉。它的優(yōu)點是實現(xiàn)簡單，效率高，不會存在內(nèi)存碎片。缺點就是需要2倍的內(nèi)存來管理。
2.標記-清理
標記清除算法分為“標記”和“清除”兩個階段：首先標記出需要回收的對象，標記完成之后統(tǒng)一清除對象。它的優(yōu)點是效率高，缺點是容易產(chǎn)生內(nèi)存碎片。
3.標記-整理
標記操作和“標記-清理”算法一致，后續(xù)操作不只是直接清理對象，而是在清理無用對象完成后讓所有 存活的對象都向一端移動，并更新引用其對象的指針。因為要移動對象，所以它的效率要比“標記-清理”效率低，但是不會產(chǎn)生內(nèi)存碎片。
基于分代的假設(shè)
由于對象的存活時間有長有短，所以對于存活時間長的對象，減少被gc的次數(shù)可以避免不必要的開銷。這樣我們就把內(nèi)存分成新生代和老年代，新生代存放剛創(chuàng)建的和存活時間比較短的對象，老年代存放存活時間比較長的對象。這樣每次僅僅清理年輕代，老年代僅在必要時時再做清理可以極大的提高GC效率，節(jié)省GC時間。
java垃圾收集器的歷史
第一階段，Serial（串行）收集器
在jdk1.3.1之前，java虛擬機僅僅能使用Serial收集器。 Serial收集器是一個單線程的收集器，但它的“單線程”的意義并不僅僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結(jié)束。
PS：開啟Serial收集器的方式
-XX:+UseSerialGC
第二階段，Parallel（并行）收集器
Parallel收集器也稱吞吐量收集器，相比Serial收集器，Parallel最主要的優(yōu)勢在于使用多線程去完成垃圾清理工作，這樣可以充分利用多核的特性，大幅降低gc時間。
PS:開啟Parallel收集器的方式
-XX:+UseParallelGC -XX:+UseParallelOldGC
第三階段，CMS（并發(fā)）收集器
CMS收集器在Minor GC時會暫停所有的應用線程，并以多線程的方式進行垃圾回收。在Full GC時不再暫停應用線程，而是使用若干個后臺線程定期的對老年代空間進行掃描，及時回收其中不再使用的對象。
PS:開啟CMS收集器的方式
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
第四階段，G1（并發(fā)）收集器
G1收集器（或者垃圾優(yōu)先收集器）的設(shè)計初衷是為了盡量縮短處理超大堆（大于4GB）時產(chǎn)生的停頓。相對于CMS的優(yōu)勢而言是內(nèi)存碎片的產(chǎn)生率大大降低。
PS:開啟G1收集器的方式
-XX:+UseG1GC
二，了解G1
G1的第一篇paper（附錄1）發(fā)表于2004年，在2012年才在jdk1.7u4中可用。oracle官方計劃在jdk9中將G1變成默認的垃圾收集器，以替代CMS。為何oracle要極力推薦G1呢，G1有哪些優(yōu)點？
首先，G1的設(shè)計原則就是簡單可行的性能調(diào)優(yōu)
開發(fā)人員僅僅需要聲明以下參數(shù)即可：
-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200
其中-XX:+UseG1GC為開啟G1垃圾收集器，-Xmx32g 設(shè)計堆內(nèi)存的最大內(nèi)存為32G，-XX:MaxGCPauseMillis=200設(shè)置GC的最大暫停時間為200ms。如果我們需要調(diào)優(yōu)，在內(nèi)存大小一定的情況下，我們只需要修改最大暫停時間即可。
其次，G1將新生代，老年代的物理空間劃分取消了。
這樣我們再也不用單獨的空間對每個代進行設(shè)置了，不用擔心每個代內(nèi)存是否足夠。
取而代之的是，G1算法將堆劃分為若干個區(qū)域（Region），它仍然屬于分代收集器。不過，這些區(qū)域的一部分包含新生代，新生代的垃圾收集依然采用暫停所有應用線程的方式，將存活對象拷貝到老年代或者Survivor空間。老年代也分成很多區(qū)域，G1收集器通過將對象從一個區(qū)域復制到另外一個區(qū)域，完成了清理工作。這就意味著，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms內(nèi)存碎片問題的存在了。
在G1中，還有一種特殊的區(qū)域，叫Humongous區(qū)域。 如果一個對象占用的空間超過了分區(qū)容量50%以上，G1收集器就認為這是一個巨型對象。這些巨型對象，默認直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負面影響。為了解決這個問題，G1劃分了一個Humongous區(qū)，它用來專門存放巨型對象。如果一個H區(qū)裝不下一個巨型對象，那么G1會尋找連續(xù)的H分區(qū)來存儲。為了能找到連續(xù)的H區(qū)，有時候不得不啟動Full GC。
PS：在java 8中，持久代也移動到了普通的堆內(nèi)存空間中，改為元空間。
對象分配策略
說起大對象的分配，我們不得不談談對象的分配策略。它分為3個階段：
- TLAB(Thread Local Allocation Buffer)線程本地分配緩沖區(qū)
- Eden區(qū)中分配
- Humongous區(qū)分配
TLAB為線程本地分配緩沖區(qū)，它的目的為了使對象盡可能快的分配出來。如果對象在一個共享的空間中分配，我們需要采用一些同步機制來管理這些空間內(nèi)的空閑空間指針。在Eden空間中，每一個線程都有一個固定的分區(qū)用于分配對象，即一個TLAB。分配對象時，線程之間不再需要進行任何的同步。
對TLAB空間中無法分配的對象，JVM會嘗試在Eden空間中進行分配。如果Eden空間無法容納該對象，就只能在老年代中進行分配空間。
最后，G1提供了兩種GC模式，Young GC和Mixed GC，兩種都是Stop The World(STW)的。下面我們將分別介紹一下這2種模式。
三，G1 Young GC
Young GC主要是對Eden區(qū)進行GC，它在Eden空間耗盡時會被觸發(fā)。在這種情況下，Eden空間的數(shù)據(jù)移動到Survivor空間中，如果Survivor空間不夠，Eden空間的部分數(shù)據(jù)會直接晉升到年老代空間。Survivor區(qū)的數(shù)據(jù)移動到新的Survivor區(qū)中，也有部分數(shù)據(jù)晉升到老年代空間中。最終Eden空間的數(shù)據(jù)為空，GC停止工作，應用線程繼續(xù)執(zhí)行。
這時，我們需要考慮一個問題，如果僅僅GC 新生代對象，我們?nèi)绾握业剿械母鶎ο竽兀?老年代的所有對象都是根么？那這樣掃描下來會耗費大量的時間。于是，G1引進了RSet的概念。它的全稱是Remembered Set，作用是跟蹤指向某個heap區(qū)內(nèi)的對象引用。
在CMS中，也有RSet的概念，在老年代中有一塊區(qū)域用來記錄指向新生代的引用。這是一種point-out，在進行Young GC時，掃描根時，僅僅需要掃描這一塊區(qū)域，而不需要掃描整個老年代。
但在G1中，并沒有使用point-out，這是由于一個分區(qū)太小，分區(qū)數(shù)量太多，如果是用point-out的話，會造成大量的掃描浪費，有些根本不需要GC的分區(qū)引用也掃描了。于是G1中使用point-in來解決。point-in的意思是哪些分區(qū)引用了當前分區(qū)中的對象。這樣，僅僅將這些對象當做根來掃描就避免了無效的掃描。由于新生代有多個，那么我們需要在新生代之間記錄引用嗎？這是不必要的，原因在于每次GC時，所有新生代都會被掃描，所以只需要記錄老年代到新生代之間的引用即可。
需要注意的是，如果引用的對象很多，賦值器需要對每個引用做處理，賦值器開銷會很大，為了解決賦值器開銷這個問題，在G1 中又引入了另外一個概念，卡表（Card Table）。一個Card Table將一個分區(qū)在邏輯上劃分為固定大小的連續(xù)區(qū)域，每個區(qū)域稱之為卡?？ㄍǔ］^小，介于128到512字節(jié)之間。Card Table通常為字節(jié)數(shù)組，由Card的索引（即數(shù)組下標）來標識每個分區(qū)的空間地址。默認情況下，每個卡都未被引用。當一個地址空間被引用時，這個地址空間對應的數(shù)組索引的值被標記為”0″，即標記為臟被引用，此外RSet也將這個數(shù)組下標記錄下來。一般情況下，這個RSet其實是一個Hash Table，Key是別的Region的起始地址，Value是一個集合，里面的元素是Card Table的Index。
Young GC 階段：
- 階段1：根掃描
靜態(tài)和本地對象被掃描 - 階段2：更新RS
處理dirty card隊列更新RS - 階段3：處理RS
檢測從年輕代指向年老代的對象 - 階段4：對象拷貝
拷貝存活的對象到survivor/old區(qū)域 - 階段5：處理引用隊列
軟引用，弱引用，虛引用處理
四，G1 Mix GC
Mix GC不僅進行正常的新生代垃圾收集，同時也回收部分后臺掃描線程標記的老年代分區(qū)。
它的GC步驟分2步：
- 全局并發(fā)標記（global concurrent marking）
- 拷貝存活對象（evacuation）
在進行Mix GC之前，會先進行g(shù)lobal concurrent marking（全局并發(fā)標記）。 global concurrent marking的執(zhí)行過程是怎樣的呢？
在G1 GC中，它主要是為Mixed GC提供標記服務的，并不是一次GC過程的一個必須環(huán)節(jié)。global concurrent marking的執(zhí)行過程分為五個步驟：
- 初始標記（initial mark，STW）
在此階段，G1 GC 對根進行標記。該階段與常規(guī)的 (STW) 年輕代垃圾回收密切相關(guān)。 - 根區(qū)域掃描（root region scan）
G1 GC 在初始標記的存活區(qū)掃描對老年代的引用，并標記被引用的對象。該階段與應用程序（非 STW）同時運行，并且只有完成該階段后，才能開始下一次 STW 年輕代垃圾回收。 - 并發(fā)標記（Concurrent Marking）
G1 GC 在整個堆中查找可訪問的（存活的）對象。該階段與應用程序同時運行，可以被 STW 年輕代垃圾回收中斷 - 最終標記（Remark，STW）
該階段是 STW 回收，幫助完成標記周期。G1 GC 清空 SATB 緩沖區(qū)，跟蹤未被訪問的存活對象，并執(zhí)行引用處理。 - 清除垃圾（Cleanup，STW）
在這個最后階段，G1 GC 執(zhí)行統(tǒng)計和 RSet 凈化的 STW 操作。在統(tǒng)計期間，G1 GC 會識別完全空閑的區(qū)域和可供進行混合垃圾回收的區(qū)域。清理階段在將空白區(qū)域重置并返回到空閑列表時為部分并發(fā)。
三色標記算法
提到并發(fā)標記，我們不得不了解并發(fā)標記的三色標記算法。它是描述追蹤式回收器的一種有用的方法，利用它可以推演回收器的正確性。 首先，我們將對象分成三種類型的。
- 黑色:根對象，或者該對象與它的子對象都被掃描
- 灰色:對象本身被掃描,但還沒掃描完該對象中的子對象
- 白色:未被掃描對象，掃描完成所有對象之后，最終為白色的為不可達對象，即垃圾對象
當GC開始掃描對象時，按照如下圖步驟進行對象的掃描：
根對象被置為黑色，子對象被置為灰色。
繼續(xù)由灰色遍歷,將已掃描了子對象的對象置為黑色。
遍歷了所有可達的對象后，所有可達的對象都變成了黑色。不可達的對象即為白色，需要被清理。
這看起來很美好，但是如果在標記過程中，應用程序也在運行，那么對象的指針就有可能改變。這樣的話，我們就會遇到一個問題：對象丟失問題
我們看下面一種情況，當垃圾收集器掃描到下面情況時：
這時候應用程序執(zhí)行了以下操作：
A.c=C
B.c=null
這樣，對象的狀態(tài)圖變成如下情形：
這時候垃圾收集器再標記掃描的時候就會下圖成這樣：
很顯然，此時C是白色，被認為是垃圾需要清理掉，顯然這是不合理的。那么我們?nèi)绾伪ＷC應用程序在運行的時候，GC標記的對象不丟失呢？有如下2中可行的方式：
- 在插入的時候記錄對象
- 在刪除的時候記錄對象
剛好這對應CMS和G1的2種不同實現(xiàn)方式：
在CMS采用的是增量更新（Incremental update），只要在寫屏障（write barrier）里發(fā)現(xiàn)要有一個白對象的引用被賦值到一個黑對象 的字段里，那就把這個白對象變成灰色的。即插入的時候記錄下來。
在G1中，使用的是STAB（snapshot-at-the-beginning）的方式，刪除的時候記錄所有的對象，它有3個步驟：
1，在開始標記的時候生成一個快照圖標記存活對象
2，在并發(fā)標記的時候所有被改變的對象入隊（在write barrier里把所有舊的引用所指向的對象都變成非白的）
3，可能存在游離的垃圾，將在下次被收集
這樣，G1到現(xiàn)在可以知道哪些老的分區(qū)可回收垃圾最多。 當全局并發(fā)標記完成后，在某個時刻，就開始了Mix GC。這些垃圾回收被稱作“混合式”是因為他們不僅僅進行正常的新生代垃圾收集，同時也回收部分后臺掃描線程標記的分區(qū)?；旌鲜嚼占缦聢D：
混合式GC也是采用的復制的清理策略，當GC完成后，會重新釋放空間。
至此，混合式GC告一段落了。下一小節(jié)我們講進入調(diào)優(yōu)實踐。
五，調(diào)優(yōu)實踐
MaxGCPauseMillis調(diào)優(yōu)
前面介紹過使用GC的最基本的參數(shù)：
-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200
前面2個參數(shù)都好理解，后面這個MaxGCPauseMillis參數(shù)該怎么配置呢？這個參數(shù)從字面的意思上看，就是允許的GC最大的暫停時間。G1盡量確保每次GC暫停的時間都在設(shè)置的MaxGCPauseMillis范圍內(nèi)。 那G1是如何做到最大暫停時間的呢？這涉及到另一個概念，CSet(collection set)。它的意思是在一次垃圾收集器中被收集的區(qū)域集合。
- Young GC：選定所有新生代里的region。通過控制新生代的region個數(shù)來控制young GC的開銷。
- Mixed GC：選定所有新生代里的region，外加根據(jù)global concurrent marking統(tǒng)計得出收集收益高的若干老年代region。在用戶指定的開銷目標范圍內(nèi)盡可能選擇收益高的老年代region。
在理解了這些后，我們再設(shè)置最大暫停時間就好辦了。 首先，我們能容忍的最大暫停時間是有一個限度的，我們需要在這個限度范圍內(nèi)設(shè)置。但是應該設(shè)置的值是多少呢？我們需要在吞吐量跟MaxGCPauseMillis之間做一個平衡。如果MaxGCPauseMillis設(shè)置的過小，那么GC就會頻繁，吞吐量就會下降。如果MaxGCPauseMillis設(shè)置的過大，應用程序暫停時間就會變長。G1的默認暫停時間是200毫秒，我們可以從這里入手，調(diào)整合適的時間。
其他調(diào)優(yōu)參數(shù)
-XX:G1HeapRegionSize=n
設(shè)置的 G1 區(qū)域的大小。值是 2 的冪，范圍是 1 MB 到 32 MB 之間。目標是根據(jù)最小的 Java 堆大小劃分出約 2048 個區(qū)域。
-XX:ParallelGCThreads=n
設(shè)置 STW 工作線程數(shù)的值。將 n 的值設(shè)置為邏輯處理器的數(shù)量。n 的值與邏輯處理器的數(shù)量相同，最多為 8。
如果邏輯處理器不止八個，則將 n 的值設(shè)置為邏輯處理器數(shù)的 5/8 左右。這適用于大多數(shù)情況，除非是較大的 SPARC 系統(tǒng)，其中 n 的值可以是邏輯處理器數(shù)的 5/16 左右。
-XX:ConcGCThreads=n
設(shè)置并行標記的線程數(shù)。將 n 設(shè)置為并行垃圾回收線程數(shù) (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=45
設(shè)置觸發(fā)標記周期的 Java 堆占用率閾值。默認占用率是整個 Java 堆的 45%。
避免使用以下參數(shù)：
避免使用 -Xmn 選項或 -XX:NewRatio 等其他相關(guān)選項顯式設(shè)置年輕代大小。固定年輕代的大小會覆蓋暫停時間目標。
觸發(fā)Full GC
在某些情況下，G1觸發(fā)了Full GC，這時G1會退化使用Serial收集器來完成垃圾的清理工作，它僅僅使用單線程來完成GC工作，GC暫停時間將達到秒級別的。整個應用處于假死狀態(tài)，不能處理任何請求，我們的程序當然不希望看到這些。那么發(fā)生Full GC的情況有哪些呢？
- 并發(fā)模式失敗
G1啟動標記周期，但在Mix GC之前，老年代就被填滿，這時候G1會放棄標記周期。這種情形下，需要增加堆大小，或者調(diào)整周期（例如增加線程數(shù)-XX:ConcGCThreads等）。
- 晉升失敗或者疏散失敗
G1在進行GC的時候沒有足夠的內(nèi)存供存活對象或晉升對象使用，由此觸發(fā)了Full GC?？梢栽谌罩局锌吹?to-space exhausted)或者（to-space overflow）。解決這種問題的方式是：
a,增加 -XX:G1ReservePercent 選項的值（并相應增加總的堆大?。瑸椤澳繕丝臻g”增加預留內(nèi)存量。
b,通過減少 -XX:InitiatingHeapOccupancyPercent 提前啟動標記周期。
c,也可以通過增加 -XX:ConcGCThreads 選項的值來增加并行標記線程的數(shù)目。
- 巨型對象分配失敗
當巨型對象找不到合適的空間進行分配時，就會啟動Full GC，來釋放空間。這種情況下，應該避免分配大量的巨型對象，增加內(nèi)存或者增大-XX:G1HeapRegionSize，使巨型對象不再是巨型對象。
由于篇幅有限，G1還有很多調(diào)優(yōu)實踐，在此就不一一列出了，大家在平常的實踐中可以慢慢探索。最后，期待java 9能正式發(fā)布，默認使用G1為垃圾收集器的java性能會不會又提高呢？
