G1垃圾收集器

G1垃圾收集器

简介

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

G1内存布局

G1的内存布局与CMS等垃圾回收器都不相同。G1虽然仍保留了年轻代、老年代的概念，但它不在是一大块连续的内存。

G1将堆划分成了若干个大小相同的Region，JVM最多可以有2048个Region（默认也是）。如一个4GB的堆内存，将会被划分成2048个Region，每个Region大小为2MB。

默认情况下，年轻代堆内存占比为5%，如果堆大小为4096MB，那么年轻代占据200MB左右的内存，对应大概100个Region，我们可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但最多年轻代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100个，s1对应100个。

但需要注意的是Region在G1中是动态的，一个Region一开始可能是年轻代，但是当垃圾回收空闲出来后，它下次可能继续作为年轻代使用，也有可能被作为老年代或Humongous使用。也就是G1中的分代，实际上是逻辑上的分代。

G1中对象什么时候进行老年代与我们之前介绍过的是一样的，唯一不同的是大对象的处理，G1中有专门分配大对象的Region叫Humongous区，当一个对象超过Region大小的50%，我们就会认为其是大对象，并将其放到Humongous区。比如，按照上面所说，每个Region是2MB，那么只要对象超过了1MB，就会被放入到Humongous，如果一个对象太多，一个Humongous放不下，就会横跨多个Region来存放。

利用Humongous专门来存放短期的大对象，而不是进入老年代，可以节约老年代的空间，避免因为老年代空间不足而触发GC。

G1垃圾回收流程

G1的垃圾回收过程与CMS极为相似，大致可以分为几个步骤：

1. 初始标记（initial mark，STW）：STW，暂停所有其他线程，标记所有gc roots能够直接引用的对象。
2. 并发标记（Concurrent Marking）：对初始标记阶段标记的对象做可达性分析，这个过程是与用户线程同步进行的。
3. 最终标记（Remark，STW）：解决并发标记阶段，由于用户线程同步运行导致的漏标问题。
4. 筛选回收（Cleanup，STW）：段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。

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

不熟悉gc roots和可达性分析的可以看这篇文章https://blog.csdn.net/qq_32099833/article/details/109253339关于漏标问题如果不清楚，可以看这篇文章https://www.cnblogs.com/hongdada/p/14578950.html

G1的特点

我认为G1最大的特点就是可预测的停顿时间，G1会将垃圾回收停顿的时间控制在-XX:MaxGCPauseMillis指定的值。

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

G1垃圾收集分类

Young gc

G1并不是Eden区放满了就会马上进行young gc，而是会计算一下目前回收Eden需要多少时间，如果回收时间远小于-XX:MaxGCPauseMillis设置的值，那么就会增加新的年轻代Region，直到下次Eden区再次放满，且回收Eden区的停顿时间接近-XX:MaxGCPauseMillis设置的值，此时才会触发young gc

mixed gc

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

full gc

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。因此我们要极力避免发生full gc

G1收集器参数设置

1. -XX:+UseG1GC:使用G1收集器
2. -XX:ParallelGCThreads:指定GC工作的线程数量
3. -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区
4. -XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
5. -XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%，值配置整数，默认就是百分比)
6. -XX:G1MaxNewSizePercent:新生代内存最大空间
7. -XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
8. -XX:MaxTenuringThreshold:最大年龄阈值(默认15)
9. -XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了
10. -XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。
11. -XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
12. -XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

什么场景适合使用G1

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

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

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

总结

最后简单总结一下这篇文章的主要内容：

1. G1是一款适用于多处理器以及大内存的垃圾收集器
2. G1采用了Region作为内存布局，支持指定预期停顿时间是G1最大的特点
3. G1垃圾回收的流程
   a. 初始标记
   b. 并发标记
   c. 最终标记
   d. 筛选回收
4. G1的垃圾收集类型有三种
   a. young gc：并不是年轻代放不下后立马触发，而是会先计算一下回收的时间是否与预期停顿时间相近，相近才会触发young gc，否则继续增加年轻代的Region
   b. mixed gc：当老年代Region占比达到一定比例时触发，会回收所有的年轻代、部分老年代和大对象
   c. full gc：全程STW，单线程收集，应极力避免
5. G1的参数设置
6. 什么场景适合使用G1