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停顿周期；防止高并发下应用雪崩现象
g1在运行过程中主要包含如下4种操作方式：
ygc（不同于cms）
并发阶段
混合模式
full gc （一般是g1出现问题时发生）
下面是一次ygc前后内存区域是示意图：
图中每个小区块都代表g1的一个区域（region），区块里面的字母代表不同的分代内存空间类型（如[e]eden,[o]old,[s]survivor）空白的区块不属于任何一个分区；g1可以在需要的时候任意指定这个区域属于eden或是o区之类的。
g1 younggc在eden充满时触发，在回收之后所有之前属于eden的区块全变成空白。然后至少有一个区块是属于s区的（如图半满的那个区域），同时可能有一些数据移到了o区。
目前淘系的应用大都使用printgcdetails参数打出gc日志、这个参数对g1同样有效、但日志内容颇为不同；下面是一个young gc的例子：
<code>23.430: [gc pause (young), 0.23094400 secs]</code>
<code>...</code>
<code>[eden: 1286m(1286m)->0b(1212m)</code>
<code>survivors: 78m->152m heap: 1454m(4096m)->242m(4096m)]</code>
<code>[times: user=0.85 sys=0.05, real=0.23 secs]</code>
上面日志的内容解析：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、下面是一个日志示例：
<code>50.541: [gc pause (young) (initial-mark), 0.27767100 secs]</code>
<code>[eden: 1220m(1220m)->0b(1220m)</code>
<code>survivors: 144m->144m heap: 3242m(4096m)->2093m(4096m)]</code>
<code>[times: user=1.02 sys=0.04, real=0.28 secs]</code>
上面的日志表明发生了ygc、应用线程为此暂停了280毫秒，eden区被清空（71mb从young区移到了o区）。
日志里面initial-mark的字样表明后台的并发gc阶段开始了。因为初始标记阶段本身也是要暂停应用线程的，
g1正好在ygc的过程中把这个事情也一起干了。为此带来的额外开销不是很大、增加了20%的cpu，暂停时间相应的略微变长了些。
接下来，g1开始扫描根区域、日志示例：
<code>50.819: [gc concurrent-root-region-scan-start]</code>
<code>51.408: [gc concurrent-root-region-scan-end, 0.5890230]</code>
一共花了580毫秒，这个过程没有暂停应用线程；是后台线程并行处理的。这个阶段不能被ygc所打断、因此后台线程有足够的cpu时间很关键。如果young区空间恰好在root扫描的时候
满了、ygc必须等待root扫描之后才能进行。带来的影响是ygc暂停时间会相应的增加。这时的gc日志是这样的：
<code>350.994: [gc pause (young)</code>
<code>351.093: [gc concurrent-root-region-scan-end, 0.6100090]</code>
<code>351.093: [gc concurrent-mark-start],0.37559600 secs]</code>
gc暂停这里可以看出在root扫描结束之前就发生了，表明ygc发生了等待，等待时间大概是100毫秒。
在root扫描完成后，g1进入了一个并发标记阶段。这个阶段也是完全后台进行的；gc日志里面下面的信息代表这个阶段的开始和结束：
<code>111.382: [gc concurrent-mark-start]</code>
<code>....</code>
<code>120.905: [gc concurrent-mark-end, 9.5225160 sec]</code>
并发标记阶段是可以被打断的，比如这个过程中发生了ygc就会。这个阶段之后会有一个二次标记阶段和清理阶段：
<code>120.910: [gc remark 120.959:</code>
<code>[gc ref-prc, 0.0000890 secs], 0.0718990 secs]</code>
<code>[times: user=0.23 sys=0.01, real=0.08 secs]</code>
<code>120.985: [gc cleanup 3510m->3434m(4096m), 0.0111040 secs]</code>
<code>[times: user=0.04 sys=0.00, real=0.01 secs]</code>
这两个阶段同样会暂停应用线程，但时间很短。接下来还有额外的一次并发清理阶段：
<code>120.996: [gc concurrent-cleanup-start]</code>
<code>120.996: [gc concurrent-cleanup-end, 0.0004520]</code>
到此为止，正常的一个g1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多（标记为x），实际空间释放较少。
接下来g1执行一系列的混合gc。这个时期因为会同时进行ygc和清理上面已标记为x的区域，所以称之为混合阶段，下面是一个混合gc执行的前后示意图：
像普通的ygc那样、g1完全清空掉eden同时调整survivor区。另外，两个标记也被回收了，他们有个共同的特点是包含最多可回收的对象，因此这两个区域绝对部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域（和ygc存活对象晋升到o区类似）。这就是为什么g1的堆比cms内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。下面是一个混合gc的日志：
<code>79.826: [gc pause (mixed), 0.26161600 secs]</code>
<code>[eden: 1222m(1222m)->0b(1220m)</code>
<code>survivors: 142m->144m heap: 3200m(4096m)->1964m(4096m)]</code>
<code>[times: user=1.01 sys=0.00, real=0.26 secs]</code>
上面的日志可以注意到eden释放了1222mb、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有16mb，但是要考虑同时有survivor区的对象晋升到o区；另外，每次混合gc只是清理一部分的o区内存，整个gc会一直持续到几乎所有的标记区域垃圾对象都被回收，这个阶段完了之后g1会重新回到正常的ygc阶段。周期性的，当o区内存占用达到一定数量之后g1又会开启一次新的并行gc阶段.