GC垃圾收集器G1

灰太狼 2022-11-17 03:57 168阅读 0赞

# JVM系列文章目录 #

提示：强大的垃圾回收器

--------------------

### 文章目录 ###

*  JVM系列文章目录
 *  前言
 *  一、G1收集器(-XX:+UseG1GC)
 *   *  被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

--------------------

# 前言 #

提示：G1（Garbadge First Collector）作为一款JVM最新的垃圾收集器，可以解决CMS中Concurrent Mode Failed问题，尽量缩短处理超大堆的停顿，在G1进行垃圾回收的时候完成内存压缩，降低内存碎片的生成。G1在堆内存比较大的时候表现出比较高吞吐量和短暂的停顿时间，而且已成为Java 9的默认收集器。未来替代CMS只是时间的问题。

--------------------

提示：希望大家给提供宝贵的建议

![在这里插入图片描述][20210408112123512.png]

# 一、G1收集器(-XX:+UseG1GC) #

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征  
较旧的垃圾收集器（串行，并行，CMS）将堆分成三个部分：固定内存大小的年轻代，旧代和永久代。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70]  
所有内存对象最终都属于这三个部分之一。

G1收集器采用了不同的方法。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 1]  
堆被划分为一组大小相等的堆区域，每个堆区域都包含一个连续范围的虚拟内存。某些区域集被分配了与较旧的收集者相同的角色（eden，幸存者，旧角色），但是它们的大小并没有固定。这在内存使用方面提供了更大的灵活性。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 2]  
这里让我们忘记Eden区与Survor区？全部忘记？但是他还是用了分代的概念，听他瞎胡说  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 3]

执行垃圾收集时，G1以类似于CMS收集器的方式运行。G1执行并发全局标记阶段，以确定整个堆中对象的活动性。标记阶段完成后，G1知道哪些区域大部分为空。它首先收集在这些区域中，通常会产生大量的自由空间。这就是为什么这种垃圾收集方法称为“垃圾优先”的原因。顾名思义，G1将其收集和压缩活动集中在可能充满可回收对象（即垃圾）的堆区域中。G1使用暂停预测模型来满足用户定义的暂停时间目标，并根据指定的暂停时间目标选择要收集的区域数。

由G1标识为可回收的成熟区域是使用疏散收集的垃圾。G1将对象从堆的一个或多个区域复制到堆上的单个区域，并且在此过程中，压缩和释放了内存。撤离是在多处理器上并行执行的，以减少暂停时间并增加吞吐量。因此，对于每个垃圾收集，G1都在用户定义的暂停时间内连续工作以减少碎片。这超出了前面两种方法的能力。CMS（并发标记扫描）垃圾收集器不会进行压缩。ParallelOld垃圾收集仅执行整个堆压缩，这导致相当长的暂停时间。

重要的是要注意，G1不是实时收集器。它很有可能达到设定的暂停时间目标，但并非绝对确定。G1根据先前收集的数据，估算在用户指定的目标时间内可以收集多少个区域。因此，收集器具有收集区域成本的合理准确的模型，并且收集器使用此模型来确定要收集哪些区域和多少区域，同时保持在暂停时间目标之内。

**注意： G1同时具有并发（与应用程序线程一起运行，例如，优化，标记，清除）和并行（多线程，例如，停止世界）阶段。完整的垃圾回收仍然是单线程的，但是如果正确调整，您的应用程序应避免使用完整的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，可以通过 **“-XX:G1NewSizePercent”** 设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的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收集器一次GC(主要值Mixed GC)的运作过程大致分为以下几个步骤：

*  **初始标记（initial mark，STW）：** 暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；
 *  **并发标记（Concurrent Marking）：** 同CMS的并发标记
 *  **最终标记（Remark，STW）：** 同CMS的重新标记
 *  **筛选回收（Cleanup，STW）：** 筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(**注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本**)  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 4]  
    **CMS的** 比比是不是很像很像 个人感觉在基础上改进了  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 5]

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 6]

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

*  **并行与并发：** G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
 *  **分代收集：** 虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
 *  **空间整合：** 与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
 *  **可预测的停顿：** 这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

如果从ParallelOldGC或CMS收集器迁移到G1，则可能会看到较大的JVM进程大小。这在很大程度上与“存储”数据结构有关，例如“记住的集”和“集合集”。

记忆集或RSets将对象引用跟踪到给定区域中。堆中每个区域有一个RSet。RSet可以并行和独立地收集区域。RSets的总体足迹影响不到5％。

集合集或CSet将在GC中收集的区域集。GC期间，将撤消（复制/移动）CSet中的所有实时数据。区域集可以是eden，幸存者和/或老一辈。CSets对JVM的大小影响不到1％。

> **G1垃圾收集分类**  
> **YoungGC** YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数  
> \-XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC  
> **MixedGC** 不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full  
> GC  
> **Full GC** 停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)

**G1收集器参数设置**

-XX:+UseG1GC:使用G1收集器
     -XX:G1MixedGCLiveThresholdPercent(默认85%)  region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。
      -XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
      -XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

**G1垃圾收集器优化建议**  
假设参数 **-XX:MaxGCPauseMills** 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。  
那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。  
所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

**什么场景适合使用G1**

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

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

**为什么G1用SATB？CMS用增量更新？**  
我的理解：SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

[20210408112123512.png]: /images/20221022/e4673298a3ba40a691e10adb7e3a0653.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70]: /images/20221022/0a237a0b5f7945d4bf3d9183635ee6f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 1]: /images/20221022/e4320279ae974cadb3baceba7eba005f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 2]: /images/20221022/1852e2c57d8e4ff3bbb61db2361fdcb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 3]: /images/20221022/c6a053ccd6e34f769609f039fd4b04cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 4]: /images/20221022/5634a14b44094d1fad9d2bceefe3d7b5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 5]: /images/20221022/efbee5cc2a3040788c1c95e2485ca7bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 6]: /images/20221022/6fcd5d84490f4adf9a54d722782f4f50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNzMxMzU4_size_16_color_FFFFFF_t_70 7]: /images/20221022/660f11c3d51c4ae5b490ffe43c95b48e.png