G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作為JVM GC選項；作為JVM GC算法的一次重大升級、DK7u后G1已相對穩定、且未來計劃替代CMS、所以有必要深入了解下：

不同于其他的分代回收算法、G1將堆空間劃分成了互相獨立的區塊。每塊區域既有可能屬于O區、也有可能是Y區，且每類區域空間可以是不連續的（對比CMS的O區和Y區都必須是連續的）。這種將O區劃分成多塊的理念源于：當并發后臺線程尋找可回收的對象時、有些區塊包含可回收的對象要比其他區塊多很多。雖然在清理這些區塊時G1仍然需要暫停應用線程、但可以用相對較少的時間優先回收包含垃圾最多區塊。這也是為什么G1命名為Garbage First的原因：第一時間處理垃圾最多的區塊。

?

平時工作中大多數系統都使用CMS、即使靜默升級到JDK7默認仍然采用CMS、那么G1相對于CMS的區別在：

G1在壓縮空間方面有優勢

G1通過將內存空間分成區域（Region）的方式避免內存碎片問題

Eden, Survivor, Old區不再固定、在內存使用效率上來說更靈活

G1可以通過設置預期停頓時間（Pause Time）來控制垃圾收集時間避免應用雪崩現象

G1在回收內存后會馬上同時做合并空閑內存的工作、而CMS默認是在STW（stop the world）的時候做

G1會在Young GC中使用、而CMS只能在O區使用

就目前而言、CMS還是默認首選的GC策略、可能在以下場景下G1更適合：

服務端多核CPU、JVM內存占用較大的應用（至少大于4G）

應用在運行過程中會產生大量內存碎片、需要經常壓縮空間

想要更可控、可預期的GC停頓周期；防止高并發下應用雪崩現象

一次完整G1GC的詳細過程：

G1在運行過程中主要包含如下4種操作方式：

YGC（不同于CMS）

并發階段

混合模式

full GC （一般是G1出現問題時發生）

YGC：

下面是一次YGC前后內存區域是示意圖：

圖中每個小區塊都代表G1的一個區域（Region），區塊里面的字母代表不同的分代內存空間類型（如[E]Eden,[O]Old,[S]Survivor）空白的區塊不屬于任何一個分區；G1可以在需要的時候任意指定這個區域屬于Eden或是O區之類的。
G1 YoungGC在Eden充滿時觸發，在回收之后所有之前屬于Eden的區塊全變成空白。然后至少有一個區塊是屬于S區的（如圖半滿的那個區域），同時可能有一些數據移到了O區。

目前淘系的應用大都使用PrintGCDetails參數打出GC日志、這個參數對G1同樣有效、但日志內容頗為不同；下面是一個Young GC的例子：

23.430: [GC pause (young), 0.23094400 secs]
...
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]

上面日志的內容解析：Young GC實際占用230毫秒、其中GC線程占用850毫秒的CPU時間
E：內存占用從1286MB變成0、都被移出
S：從78M增長到了152M、說明從Eden移過來74M
Heap:占用從1454變成242M、說明這次Young GC一共釋放了1212M內存空間
很多情況下，S區的對象會有部分晉升到Old區，另外如果S區已滿、Eden存活的對象會直接晉升到Old區，這種情況下Old的空間就會漲

并發階段：

一個并發G1回收周期前后內存占用情況如下圖所示：

從上面的圖表可以看出以下幾點：
1、Young區發生了變化、這意味著在G1并發階段內至少發生了一次YGC（這點和CMS就有區別），Eden在標記之前已經被完全清空，因為在并發階段應用線程同時在工作、所以可以看到Eden又有新的占用
2、一些區域被X標記，這些區域屬于O區，此時仍然有數據存放、不同之處在G1已標記出這些區域包含的垃圾最多、也就是回收收益最高的區域
3、在并發階段完成之后實際上O區的容量變得更大了（O+X的方塊）。這時因為這個過程中發生了YGC有新的對象進入所致。此外，這個階段在O區沒有回收任何對象：它的作用主要是標記出垃圾最多的區塊出來。對象實際上是在后面的階段真正開始被回收

G1并發標記周期可以分成幾個階段、其中有些需要暫停應用線程。第一個階段是初始標記階段。這個階段會暫停所有應用線程-部分原因是這個過程會執行一次YGC、下面是一個日志示例：

50.541: [GC pause (young) (initial-mark), 0.27767100 secs]
[Eden: 1220M(1220M)->0B(1220M)
Survivors: 144M->144M Heap: 3242M(4096M)->2093M(4096M)]
[Times: user=1.02 sys=0.04, real=0.28 secs]

上面的日志表明發生了YGC、應用線程為此暫停了280毫秒，Eden區被清空（71MB從Young區移到了O區）。
日志里面initial-mark的字樣表明后臺的并發GC階段開始了。因為初始標記階段本身也是要暫停應用線程的，
G1正好在YGC的過程中把這個事情也一起干了。為此帶來的額外開銷不是很大、增加了20%的CPU，暫停時間相應的略微變長了些。

接下來，G1開始掃描根區域、日志示例：

50.819: [GC concurrent-root-region-scan-start]
51.408: [GC concurrent-root-region-scan-end, 0.5890230]

一共花了580毫秒，這個過程沒有暫停應用線程；是后臺線程并行處理的。這個階段不能被YGC所打斷、因此后臺線程有足夠的CPU時間很關鍵。如果Young區空間恰好在Root掃描的時候
滿了、YGC必須等待root掃描之后才能進行。帶來的影響是YGC暫停時間會相應的增加。這時的GC日志是這樣的：

350.994: [GC pause (young)
351.093: [GC concurrent-root-region-scan-end, 0.6100090]
351.093: [GC concurrent-mark-start],0.37559600 secs]

GC暫停這里可以看出在root掃描結束之前就發生了，表明YGC發生了等待，等待時間大概是100毫秒。
在root掃描完成后，G1進入了一個并發標記階段。這個階段也是完全后臺進行的；GC日志里面下面的信息代表這個階段的開始和結束：

111.382: [GC concurrent-mark-start]
....
120.905: [GC concurrent-mark-end, 9.5225160 sec]

并發標記階段是可以被打斷的，比如這個過程中發生了YGC就會。這個階段之后會有一個二次標記階段和清理階段：

120.910: [GC remark 120.959:
[GC ref-PRC, 0.0000890 secs], 0.0718990 secs]
[Times: user=0.23 sys=0.01, real=0.08 secs]
120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]
[Times: user=0.04 sys=0.00, real=0.01 secs]

這兩個階段同樣會暫停應用線程，但時間很短。接下來還有額外的一次并發清理階段：

120.996: [GC concurrent-cleanup-start]
120.996: [GC concurrent-cleanup-end, 0.0004520]

到此為止，正常的一個G1周期已完成–這個周期主要做的是發現哪些區域包含可回收的垃圾最多（標記為X），實際空間釋放較少。

混合GC：

接下來G1執行一系列的混合GC。這個時期因為會同時進行YGC和清理上面已標記為X的區域，所以稱之為混合階段，下面是一個混合GC執行的前后示意圖：

像普通的YGC那樣、G1完全清空掉Eden同時調整survivor區。另外，兩個標記也被回收了，他們有個共同的特點是包含最多可回收的對象，因此這兩個區域絕對部分空間都被釋放了。這兩個區域任何存活的對象都被移到了其他區域（和YGC存活對象晉升到O區類似）。這就是為什么G1的堆比CMS內存碎片要少很多的原因–移動這些對象的同時也就是在壓縮對內存。下面是一個混合GC的日志：

79.826: [GC pause (mixed), 0.26161600 secs]
....
[Eden: 1222M(1222M)->0B(1220M)
Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]
[Times: user=1.01 sys=0.00, real=0.26 secs]

上面的日志可以注意到Eden釋放了1222MB、但整個堆的空間釋放內存要大于這個數目。數量相差看起來比較少、只有16MB，但是要考慮同時有survivor區的對象晉升到O區；另外，每次混合GC只是清理一部分的O區內存，整個GC會一直持續到幾乎所有的標記區域垃圾對象都被回收，這個階段完了之后G1會重新回到正常的YGC階段。周期性的，當O區內存占用達到一定數量之后G1又會開啟一次新的并行GC階段.

原創文章，轉載請注明：?轉載自并發編程網 – ifeve.com

轉載于:https://www.cnblogs.com/remagon/p/4440767.html

總結

以上是生活随笔為你收集整理的[转]深入理解G1垃圾收集器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。