一文搞懂G1垃圾回收器

G1是从JDK9之后的默认垃圾回收器，其功能强大，性能优异，不过目前市面的材料不算多，很多都是抄来抄去，讲得也不太清楚。经过仔细阅读oracle官网以及相关的材料，从整体上梳理了G1的过程，希望这一文能帮你真正搞懂G1垃圾回收器。

目录

1 基本特征

2 图解G1对象分配与回收过程

3 深入理解G1垃圾回收过程

3.1 YoungGC过程

3.2 FullGC和MixGC 过程

---

1 基本特征

G1从JDK7开始就有了，从JDK9开始就是默认的垃圾回收器了，开启的方法是收集器(-XX:+UseG1GC)。

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征。

G1中不再将整个堆空间分代，而是将Java堆划分为多个大小相等的独立区域（Region），JVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)，实际可以超过该值，但是不推荐。

一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。 如下图所示：

 G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。

默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100个，s1对应100个。

一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。

G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

那 什么场景适合使用G1呢？主要是以下几种场景：

1. 50%以上的堆被存活对象占用

2. 对象分配和晋升的速度变化非常大

3. 垃圾回收时间特别长，超过1秒

4. 8GB以上的堆内存(建议值)

5. 停顿时间是500ms以内

案例：每秒几十万并发的系统如何优化JVM

Kafka类似的支撑高并发消息系统大家肯定不陌生，对于kafka来说，每秒处理几万甚至几十万消息时很正常的，一般来说部署kafka需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理，这里就涉及到一个问题了，我们以前常说的对于eden区的young gc是很快的，这种情况下它的执行还会很快吗？很显然，不可能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按kafka这个并发量放满三四十G的eden区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为young gc卡顿几秒钟没法处理新消息，显然是不行的。那么对于这种情况如何优化了，我们可以使用G1收集器，设置 -XX:MaxGCPauseMills 为50ms，假设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。

G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。

2 图解G1对象分配与回收过程

初始阶段，对空间被分割为很多固定大小的区域。

 然后很多区域会不断被分配对象，此时很多区域慢慢变成年轻代、存活代和老年代，如下图所示：

 那对象分配的时候是如何一步步变成上面这样是不同类型的分区的呢？为了简化，我们先假定所有的区域的大小都是一样的。此时新创建的对象与CMS一样是先分配在新生代Eden区的。如下图：

 当分配到一定程度之后，很多Eden区域满了，会启动年轻代进行垃圾回收，此时上述Eden区域里活的对象会被集中分配一个一个区域里，这个区域也就被标记为S区，如下：、

 此时被执行垃圾回收的E区都会被释放掉。

如果我们继续分配，当Eden区再次填满时，会再次触发垃圾回收，此时E区和S区中活的对象都会再次被分配到一个新的S区。当某个对象存活的时候大于规定值，就会将其放到老年代，也就是O区。如下所示：

 注意在上图中有两个S区，E区被回收时，活的对象直接被移动到S区，但是S区里的活对象被移动时被先判断生存时间，如果大于阈值的会被移动到O区，否则仍然被移动到新的S区。

事实上，G1在执行的时候，上面的过程是并发的，也就是可能会用到多个O区，例如：

 上图经过回收之后最终变成如下的样子：

 这就是G1垃圾回收的基本过程。假如再考虑大对象，一般就不会按照上面的方式来回复制，而是直接将其存档一个H区域中，如下图所示：

3 深入理解G1垃圾回收过程

我们上面通过图示看了G1的垃圾回收过程 ，但是很多地方还不严谨，我们继续讨论。

首先，通过上面的说明可以看到G1垃圾收集不是一种类型，而是三种类型：

第一种：年轻代垃圾回收 YoungGC

YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC。

第二种，混合垃圾回收，MixedGC

不是FullGC，老年代的堆占有率达到设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC。

第三种，Full GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)。

3.1 YoungGC过程

对于YoungGC垃圾回收是比较简单的，如下图，Young区域，也就是Eden区域，执行垃圾回收时，直接将各个区域里活的对象集中复制到一个S区里：

 执行完成之后的样子：

 该过程仍然是一个STW过程，但是执行快、耗时少，也不会影响用户线程的执行。

3.2 FullGC和MixGC 过程

上面我们解释过混合GC和FullGC， 正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC。因此两者在执行过程上基本是一致的，所以我们看一下完整的过程。

我们再来具体看一下具体如何进行垃圾回收的。G1收集器一次GC(主要值Mixed GC)的运作过程大致分为以下几个典型的步骤。

第一步：初始标记（initial mark,STW)

暂停所有的线程，并记录下gc roots直接能引用的对象，速度很快 ；

第二步，并发标记（Concurrent Marking）

同CMS的并发标记，扫描整个堆空间，该过程中用户线程仍然是可以执行的。不过如果此时Young GC执行了，并发标记会被中断。

 第三步：最终标记（Remark，STW）

同CMS的重新标记，此时会使用STAB表来进行，速度会被CMS快很多。此时也会将空的区域直接回收。

 第四步：筛选回收（Cleanup，STW）

G1会优先选择存活率最少的区域来回收，因为这样回收起来更容易。

 回收之后的结构：

 筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

总结一下 G1的大致过程如下：

G1的过程与CMS的Full GC 有些过程类似，但是也有很多优化，主要体现在以下几个方面：

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。

• 空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

毫无疑问， 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过， 这里设置的“期望值”必须是符合实际的， 不能异想天开， 毕竟G1是要冻结用户线程来复制对象的， 这个停顿时间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒， 一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发Full GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

G1垃圾收集器优化建议

假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。

那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。

或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。

所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

参考材料：

Getting Started with the G1 Garbage Collector

Part 1: Introduction to the G1 Garbage Collector