GC（G1算法）

最新推荐文章于 2024-08-06 14:16:48 发布

安然_随心

最新推荐文章于 2024-08-06 14:16:48 发布

阅读量1w

点赞数 3

分类专栏： JAVA Java 编程文章标签： GC

JAVA 同时被 2 个专栏收录

72 篇文章 0 订阅

订阅专栏

Java 编程

54 篇文章 2 订阅

订阅专栏

Java 8 默认的 GC是Parallel GC。Oracle正在考虑将JEP 248包含到Java 9的JEP列表中，即在服务器配置中将G1作为默认垃圾收集器。The Garbage-First (G1) garbage collector is fully supported in Oracle JDK 7 update 4 and later releases

Garbage First(G1)

G1是一个适用于服务器端、大内存、多CPU情景的垃圾收集器，主要目标是在维持高效率回收(high thoughput)的同时，提供软实时中断特性。用户可以指定一个时间上限，如果垃圾回收导致的程序暂停超过了用户设定的时间上限，会打断垃圾回收，恢复程序的执行。（备注：g1的主要目标是维持高回收率的同时，减少停顿。因为这个特定，并不是最快的，Parallel gc目前是最快的）

使用的收集算法：标记-清理，拷贝-复制

The regions identified by G1 as ripe for reclamation are garbage collected using evacuation. G1 copies objects from one or more regions of the heap to a single region on the heap, and in the process both compacts and frees up memory.

G1与CMS对比有一下不同：

1.分代： CMS中，堆被分为PermGen，YoungGen，OldGen；而YoungGen又分了两个survivo区域。在G1中，堆被平均分成几个区域(region)，在每个区域中，虽然也保留了新老代的概念，但是收集器是以整个区域为单位收集的。

2.算法：相对于CMS的“标记——清理”算法，G1会使用压缩算法，保证不产生多余的碎片。收集阶段，G1会将某个区域存活的对象拷贝的其他区域，然后将整个区域整个回收。

3.停顿时间可控：为了缩短停顿时间，G1建立可预存停顿模型，这样在用户设置的停顿时间范围内，G1会选择适当的区域进行收集，确保停顿时间不超过用户指定时间。

oracle管网的上的说法是：
1.压缩的： G1 is a compacting collector. G1 compacts sufficiently to completely avoid the use of fine-grained free lists for allocation, and instead relies on regions. This considerably simplifies parts of the collector, and mostly eliminates potential fragmentation issues
2.低停顿和可预测的停顿时间模型

运作过程

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

•初始标记（Initial Marking）
•并发标记（Concurrent Marking）
•最终标记（Final Marking）
•筛选回收（Live Data Counting and Evacuation）
对CMS收集器运作过程熟悉的读者，一定已经发现G1的前几个步骤的运作过程和CMS有很多相似之处。初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。而最终标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，从Sun透露出来的信息来看，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。通过图1可以比较清楚地看到G1收集器的运作步骤中并发和需要停顿的阶段。
这里写图片描述

对比：
CMS的停顿时间
这里写图片描述

停顿时间模型的建立

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内获可以获取尽可能高的收集效率。

不同区域间的相互引用的处理

G1把内存“化整为零”的思路，理解起来似乎很容易理解，但其中的实现细节却远远没有现象中简单，否则也不会从04年Sun实验室发表第一篇G1的论文拖至今将近8年时间都还没有开发出G1的商用版。笔者举个一个细节为例：把Java堆分为多个Region后，垃圾收集是否就真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在：Region不可能是孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那在做可达性判定确定对象是否存活的时候，岂不是还得扫描整个Java堆才能保障准确性？这个问题其实并非在G1中才有，只是在G1中更加突出了而已。在以前的分代收集中，新生代的规模一般都比老年代要小许多，新生代的收集也比老年代要频繁许多，那回收新生代中的对象也面临过相同的问题，如果回收新生代时也不得不同时扫描老年代的话，Minor GC的效率可能下降不少。

在G1收集器中Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用 Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查引是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。