JVM垃圾收集器三：G1(Garbage First)

一、简介

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

G1将Java堆划分为多个大小相等的独立区域（Region）(-XX:G1HeapRegionSize)，有Eden区、Survivor区、Old区和Humongous区。

JVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)，实际可以超过该值，但是不推荐。

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

年轻代在堆内存的占比默认是5%(-XX:G1NewSizePercent -XX:G1MaxNewSizePercent)

如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比

在系统运行中，JVM会不断的给年轻代分配更多的Region，但是年轻代的占比不会超过60%

可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100个，s1对应100个。

Humongous区：Humongous区专门用来存放大对象，而不是让大对象直接进入到老年代的Region中，可以节约老年代的空间，避免因为老年代空间不够而产生GC

在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

被视为JDK1.8及以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

• 可预测停顿：降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能够建立可预测的停顿时间模型，能让使用者指定在一个长度为M毫秒的时间片段(-XX:MaxGCPauseMillis)内完成垃圾收集。
• 空间整合：与CMS的“标记-清理”算法不同，G1从整体上来看是基于“标记-整理”算法；从局部上来看是基于“标记-复制”算法。
• 并行与并发：G1能够充分利用多CPU来缩短STW时间。
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。

二、垃圾回收过程

G1的收集过程(主要是Mixed GC)主要分为四个阶段：

• 初始标记（initial mark，STW）：同CMS的初始标记

• 并发标记（Concurrent Marking）：同CMS的并发标记

• 最终标记（Remark，STW）：同CMS的重新标记

• 筛选回收（Cleanup，STW）：

  G1收集器维护了一个优先列表，在筛选回收阶段首先对各个Region的回收价值和成本进行排序，然后再根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)

  例如：老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。

  这种使用Region内存布局以及有优先级的区域回收方式，保证了G1收集器在有限时间内达到尽可能高的收集效率。

  比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。

  这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

  不管是年轻代或是老年代，主要用的是标记-复制算法，将一个region中的存活对象复制到另一个region中，几乎不会有太多内存碎片。

  注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本

三、G1垃圾收集分类

YoungGC

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

MixedGC

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

Full GC

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

Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

四、G1的核心参数详解

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%，值配置整数，默认就是百分比)

-XX:G1MaxNewSizePercent:新生代内存最大空间

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold:最大年龄阈值(默认15)

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

五、应用场景

Kafka、ElasticSearch等

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

1. 8GB以上的堆内存(建议值)
2. 停顿时间是500ms以内
3. 50%以上的堆被存活对象占用
4. 对象分配和晋升的速度变化非常大
5. 垃圾回收时间特别长，超过1秒