这是我参与11月更文挑战的第27天，活动详情查看：2021最后一次更文挑战
G1 收集器
G1 收集器是面向服务端的一款垃圾收集器。其设计目标是为了取代 CMS 收集器的。G1 收集器有内存整理的过程，所以不会产生内存碎片，而且 STW 的停顿时间更加可控，G1 收集器添加了预测机制，用户可以指定停顿时间。
1 Region
在传统的垃圾收集器中，新生代和老年代的内存是连续的。而在 G1 收集器虽然保留了新生代和老年代，但是他们的内存可以是不连续的。G1 收集器把内存划分为一个个的 Region，新生代和老年代由许多不连续的 Region 组成。
可以看到，虽然保留了新生代和老年代的概念，但是二者之间不再是物理隔离了。而是由不同的 Region 构成。在 G1 收集器之前的其他收集器都是在整个新生代，或者老年代范围内进行垃圾收集，G1 收集器则是在 Region 内进行。G1 收集器会维护一个优先列表，根据回收时间，优先回收价值最大的 Region。G1 收集器的内存碎片整理也是在两个不同的 Region 之间通过”复制“算法进行的。
可以通过 -XX:G1HeapRegionSize设定一个 Region 的大小，取值范围从1M到32M，且是2的指数。
2 Remembered Set
我们之前说过 GC 是发生在新生代或者是老年代的。但是在进行可达性分析时，我们似乎有意避开了一个特殊的情况。如果老年代的对象引用了新生代的对象，那么在进行 新生代的 GC 时，我们需要进行整个老年代的扫描，获取引用关系，停顿时间将大大提高。
其实 JVM 并没有在新生代 GC 时扫描整个老年代。而是利用了空间换时间的办法。JVM 使用了一种叫卡表(Card Table)的数据结构来记录老年代对象到新生代的引用，当一个对象的引用关系发生改变时，首先去更新这张表（这个动作称为 Write Barrier 或者叫写屏障）。这样，在新生代进行 GC 时可以扫描这张表获取引用关系，而不必扫描整个老年代。
同样的问题，在 G1 收集器里也会出现。如果出现跨 Region 之间的引用关系，就需要扫描所有的 Region 了。与卡表类似，在 G1 收集器里出现了 Remembered Set，它的主要功能就是解决跨 Region 的引用问题。在 G1 中每一个 Region 都有一个与之对应的 Remembered Set，在进行引用类型的写操作时，同样会产生写屏障，然后会检查是否属于两个不同的 Region，如果是的话，会将卡表里的信息同步到对应的 Remembered Set 中，同样在进行 GC 时，只要扫描 Remembered Set 就可以了。
3 GC 过程
G1 的收集过程与 CMS 很相似。主要分为 4 个步骤：
-
初始标记（Initial Marking）
初始阶段标记 GC Roots 能直接关联到的对象。这一阶段需要停顿线程，但是耗时较短。
-
并发标记（Concurrent Marking）
这一阶段是进行对象的可达性分析。耗时较长，但是可以与用户线程并行。
-
最终标记（Final Marking）
同样，这一阶段是为了修正在并发标记时用户线程变更的内容。其实是 JVM 把并发标记阶段的变更都记录在了 Remembered Set Logs 里，在这一阶段只要把 Remembered Set Logs 的数据合并到 Remembered Set 里就可以了。这一阶段需要停顿线程，但是可以并行标记。
-
筛选回收（Live Data Counting and Evacuation）
这一阶段首先对各个 Region 进行排序，然后根据设定的停顿时间来定制回收计划。最后进行垃圾回收。