JVM（Java Virtual Machine）G1收集器篇

心已赠人 2024-02-20 08:46 45阅读 0赞

## 前言 ##

本文参考《深入理解Java虚拟机》，本文主要介绍G1收集器的收集思想和具体过程（填上一篇文章留下的坑）

本系列其他文章链接：  
[JVM（Java Virtual Machine）内存模型篇][JVM_Java Virtual Machine]  
[JVM（Java Virtual Machine）垃圾收集算法篇][JVM_Java Virtual Machine 1]  
[JVM（Java Virtual Machine）垃圾收集器篇][JVM_Java Virtual Machine 2]

## G1（Garbage First）收集器 ##

G1是一款主要面向服务端应用的垃圾收集器。它诞生的目的就是取代CMS的位置，或者说是“代替者”和“继承人”。开发者在设计之初，就是希望能建立一个“停顿时间模型”的收集器。

> 停顿时间模型：能够支持指定在一个长度为x毫秒的时间片段内，消耗的垃圾收集时间大概率不超过x毫秒这样的目标

所以G1就在这样的希望下，被创造出来了

### G1的“化整为零” ###

在G1收集器中，它将连续的堆划分为大小相等的独立的区域（Region），每个Region都可以根据需要，扮演新生代的Eden、Survivor空间或者老年代空间，**这些空间大小都是动态变化的**，不再和以前的收集器一样限定分区空间大小。

除此之外，Region还有一类Humongous区域，这部分区域是专门为大对象准备的。

> 大对象判定：每个对象超过Region容量一半以上就算大对象

所以基于以上分区下，G1的垃圾收集就没有Minor GC、Major GC、Full GC 这种概念了，它采用的是Mixed GC，也就是说，G1可以对堆中的任何部分来组成回收集合（Collection Set），通俗就是“打包一起丢”，它的衡量标准是：`哪块内存中存放的垃圾数量最多，回收价值越大，就在规定的时间内优先处理这些垃圾`

因此为了知道那个区域最优价值，所以也需要维护一个优先列表，每次GC，从列表中取最优的，这也是为什么叫“Garbage First”的原因。

基于以上，G1中，堆的内存布局可能是这样的：  
![在这里插入图片描述][0d68e645b5944f1b8ae9b5383feefbf8.png_pic_center_x240]

### G1存在的关键问题已经如何解决的 ###

*  **问**：Region里面存在跨Region引用对象如何解决？

> 答：  
> 使用记忆集，但这个记忆集会比其他垃圾器的记忆集更为复杂，G1 至少要花费相当于Java堆容量的10%~20%来对这个记忆集进行维护工作。 每个Region的记忆集不就记录下当前Region指向的其他Region的地址，而且还有别人指向自己的并标记这些指针分别在哪些卡页范围之内，也就是 `“我指向谁，谁指向我”的记忆集`。
> 
> > 补充内容：记忆集可以避免垃圾扫描时进行全堆扫描节约时间

*  **问**：并发标记阶段如何保证收集线程与用户线程互不干扰地运行？

> 答：  
> 在回答这个问题前，我们需要了解两个概念：“增量更新”和“原始快照”
> 
> >  *  增量更新：在并发标记过程中，用户线程新对象在GC Root上的某个Node相关联时，我们将这个新来的引用记录下来，并发标记结束后，重新对Node进行扫描，查看是否任然是关联关系。
> >  *  原始快照（SATB算法）：对当前堆的关联关系进行快照保存，不管中途是新增还是删除，并发标记过程中，根据快照的关联关系进行扫描
> 
> 在了解上面两个概念后，就可以回答这个问题了，G1使用的是原始快照，当然具体实现上肯定不止这么简单！！！
> 
> --------------------
> 
> 此外，G1为每个Region设计了两个名为：TAMS（Top at Mark Start）的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置上。G1收集器默认这个地址上的对象是被隐式标记过了，即默认他们是存活的。

*  **问**：怎样建立起可靠的停顿预测模型？

> 答：  
> G1 收集器的停顿预测模型是以“衰减均值”为理论基础来实现的，在垃圾收集过程，G1收集器会记录每个Region的一些数据，例如：记忆集里面的脏数据、回收耗时等数据，进行计算，最终根据这个值来确认回收价值，在规定时间内，每次回收价值最大的。（详细过程，读者可以自行了解，这里不做过多赘述OWO）

### G1的垃圾收集过程 ###

G1的垃圾收集大致分为下面四个步骤：

*  **初始标记（Initial Marking）**：
    
     *  需要停顿线程，但是耗时非常短。
     *  仅标记GC Roots能直接关联到的对象，比修改TAMS的值，让下一阶段用户线程并发能正确在Region中分配对象
 *  **并发标记（Concurrent Marking）**：
    
     *  与用户线程并发
     *  从GC Roots中递归查找可以回收的对象，耗时较长（对象数量决定）， 扫描结束后，还需要重新处理SATB记录下的并发时有引用变动的对象
 *  **最终标记（Final Marking）**：
    
     *  用户线程短暂停顿
     *  用于处理并发阶段结束后遗留下来的最后那少量的SATB记录
 *  **筛选回收（Live Data Counting and Evacuation）**:
    
     *  暂停用户线程，并发回收
     *  对Region中的价值进行排序，然后打包多块Region收集，把存活的Region复制到另一个Region中，然后情况当前Region。这个过程设计对象移动所以需要暂停用户线程。
     *  堆内回收示意：![在这里插入图片描述][38888b53c6764aaba5bbc9a5fc98bbe8.png_pic_center]

到这一步其实也能看出来G1在一定程度上，不仅仅为了低延迟，还想方设法保证吞吐量，不然再最后回收阶段，他任然可以并发用户线程（ZGC是如此），下图是G1收集器运行过程图：  
![在这里插入图片描述][0136ce320b474f08bf57591ef308fc2e.png_pic_center]

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

END  希望能对你有帮助

[JVM_Java Virtual Machine]: https://blog.csdn.net/weixin_59216829/article/details/133903217
[JVM_Java Virtual Machine 1]: https://blog.csdn.net/weixin_59216829/article/details/133926536
[JVM_Java Virtual Machine 2]: https://blog.csdn.net/weixin_59216829/article/details/133973319
[0d68e645b5944f1b8ae9b5383feefbf8.png_pic_center_x240]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/d0e9ab5207c043f5913b86c5a27fe3f3.png
[38888b53c6764aaba5bbc9a5fc98bbe8.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/357779ed49c2400e9a4320db6f587b60.png
[0136ce320b474f08bf57591ef308fc2e.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/4ed6a0efd5284ccaa101847326472845.png