java g1 gc ref proc_深入理解垃圾收集器的G1及日志分析

尽管Hotspot 最新的垃圾回收器G1是在2006年推出的。但是G1从推行至今的市场反响来看，但现在足以证明这款垃圾收集器是经得起考验的，从java9开始，就默认为G1垃圾收集器。G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是(在比较长期的)未来可以替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点。

并行与并发、分代收集的垃圾收集算法、可预测的停顿、空间整合。

特点

从分代来看，G1依然属于分代垃圾收集器，她会区分年轻代和老年代，依然有eden区和survivor区，但从堆的结构来看，它并不要求整个eden、年轻代或者老年代都连续，它使用了分区算法。

并行性: 在回收期间，可以由多个GC线程同时工作，有效利用多核计算能力。

井发性： GI 拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此一 般来说，不会在整个回收期间完全阻塞应用程序。

分代 GC : Gl 依然是一个分代收集器，但是和之前回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，它们或者工作在年轻代，或者工作在老年代。因此，这里是一个很大的不同。

空间整理： Gl 在回收过程中，会进行适当的对象移动，不像CMS,只是简单地标记清理对象，在若干次 GC 后，CMS 必须进行一次碎片整理。而Gl不同，它每次回收都会有效地复制对象，减少空间碎片。

G1把内存“化整为零”的思路，理解起来似乎很容易，但其中的实现细节却远远没有想象中那样简单，否则也不会从2004年Sun实验室发表第一篇G1的论文开始直到今天(将近10年时间)才开发出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的RememberedSet之中。当进行内存回收时，在GC根节点的枚举