引言

G1(Garbage First)垃圾收集器是当今垃圾回收技术最前沿的成果之一。早在JDK7就已加入JVM的收集器大家庭中，成为HotSpot重点发展的垃圾回收技术，JDK9 默认就是使用的G1垃圾收集器。

不同于其他的分代回收算法、G1最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集器甚至CMS的众多缺陷。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必须是连续的）。

平时工作中大多数系统都使用CMS、那么G1相对于CMS的区别在：

1、G1在压缩空间方面有优势

2、G1通过将内存空间分成区域（Region）的方式避免内存碎片问题

3、Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活

4、G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象

5、G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做

6、G1会在Young GC中使用、而CMS只能在O区使用

就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：

1、服务端多核CPU、JVM内存占用较大的应用（至少大于4G）

2、应用在运行过程中会产生大量内存碎片、需要经常压缩空间

3、想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象

一次完整G1GC的详细过程：

G1在运行过程中主要包含如下4种操作方式：

1、YGC（不同于CMS）

2、并发阶段

3、混合模式

4、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的例子

上面日志的内容解析：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。

下面是一个日志示例：

上面的日志表明发生了YGC、应用线程为此暂停了280毫秒，Eden区被清空（71MB从Young区移到了O区）。日志里面initial-mark的字样表明后台的并发GC阶段开始了。因为初始标记阶段本身也是要暂停应用线程的， G1正好在YGC的过程中把这个事情也一起干了。为此带来的额外开销不是很大、增加了20%的CPU，暂停时间相应的略微变长了些。

接下来，G1开始扫描根区域、日志示例：

一共花了580毫秒，这个过程没有暂停应用线程；是后台线程并行处理的。这个阶段不能被YGC所打断、因此后台线程有足够的CPU时间很关键。如果Young区空间恰好在Root扫描的时候满了、YGC必须等待root扫描之后才能进行。带来的影响是YGC暂停时间会相应的增加。这时的GC日志是这样的：

GC暂停这里可以看出在root扫描结束之前就发生了，表明YGC发生了等待，等待时间大概是100毫秒。在root扫描完成后，G1进入了一个并发标记阶段。这个阶段也是完全后台进行的；

GC日志里面下面的信息代表这个阶段的开始和结束：

并发标记阶段是可以被打断的，比如这个过程中发生了YGC就会。这个阶段之后会有一个二次标记阶段和清理阶段：

这两个阶段同样会暂停应用线程，但时间很短。接下来还有额外的一次并发清理阶段：

到此为止，正常的一个G1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多（标记为X），实际空间释放较少。

混合GC：

接下来G1执行一系列的混合GC。这个时期因为会同时进行YGC和清理上面已标记为X的区域，所以称之为混合阶段。

下面是一个混合GC执行的前后示意图：

像普通的YGC那样、G1完全清空掉Eden同时调整survivor区。另外，两个标记也被回收了，他们有个共同的特点是包含最多可回收的对象，因此这两个区域绝对部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域（和YGC存活对象晋升到O区类似）。这就是为什么G1的堆比CMS内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。

下面是一个混合GC的日志：

上面的日志可以注意到Eden释放了1222MB、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有16MB，但是要考虑同时有survivor区的对象晋升到O区；另外，每次混合GC只是清理一部分的O区内存，整个GC会一直持续到几乎所有的标记区域垃圾对象都被回收，这个阶段完了之后G1会重新回到正常的YGC阶段。周期性的，当O区内存占用达到一定数量之后G1又会开启一次新的并行GC阶段

转自：https://mp.weixin.qq.com/s/8NkjFJ_Uy0CStZNKxZUR2g