持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第28天，点击查看活动详情
1card table 卡表和RSet解决跨代引用
在CMS中有Rset的概念，但是是在老年代中。
- 在CMS中，也有RSet的概念，在老年代中有一块区域用来记录指向新生代的引用。这是一种point-out，在进行Young GC时，扫描根时，仅仅需要扫描这一块区域，而不需要扫描整个老年代。
- 但在G1中，并没有使用point-out，这是由于一个分区太小，分区数量太多，如果是用point-out的话，会造成大量的扫描浪费，有些根本不需要GC的分区引用也扫描了。
- 于是G1中使用point-in来解决。point-in的意思是哪些分区引用了当前分区中的对象。这样，仅仅将这些对象当做根来扫描就避免了无效的扫描。
总结就是我们需要用到G1中分区Region，尽量进行精确查找找到Region。（CMS中引用都是存在一起的，每次都需要遍历老年代那块区域中所有的引用）
如下是G1的卡表和 Rset示意图：
Rset(rember set)：每个region对应一个RSet，这个数据结构里记录了哪些其他region包含了指向这个region的对象的引用；这个RSet记录的是从别的region指向该region的card。所以这是一种“points-into”的Remembered Set。
（key经过hash计算进行散列来确定在Card Tble中的位置，然后再这个card table块中具体查找region，就和hashmap中key value的查找类似）
Card Table：
- 需要注意的是，如果引用的对象很多，赋值器需要对每个引用做处理，赋值器开销会很大，为了解决赋值器开销这个问题，在G1中又引入了另外一个概念，卡表（Card Table）。一个Card Table将一个分区在逻辑上划分为固定大小的连续区域，每个区域称之为卡。卡通常较小，介于128到512字节之间。Card Table通常为字节数组，由Card的索引（既数组下标）来标识每个分区的空间地址。
- 默认情况下，每个卡都未被引用。当一个地址空间被引用时，这个地址空间对应的数组索引的值被标记为“0”，既标记为被引用，此外RSet也将这个数组下标记录下来。一般情况下，这个RSet其实是一个Hash Table，key是别的Region的起始地址，Value记录了他们之间的引用关系。
2 SATB解决新创建对象漏标问题
TAB全称Snapshot-At-The-Beginning，SATB算法机制中，会在GC开始时先创建一个对象快照，在并发标记时所有快照中当时的存活对象就认为是存活的，标记过程中新分配的对象也会被标记为存活对象，不会被回收。这种机制能够很好解决新创建对象漏标的情况。STAB核心的两个结构就是两个Bitmap。
Bitmap分别存储在每个Region中，并发标记过程里的两个重要的变量：preTAMS(pre-top-at-mark-start，代表着Region上一次完成标记的位置) 以及nextTAMS（next-top-at-mark-start，随着标记的进行会不断移动，一开始在top位置）。SATB通过控制两个变量的移动来进行标记，移动规则如下：
- 假设第n轮并发标记开始，将该Region当前的Top指针赋值给nextTAMS，在并发标记标记期间，分配的对象都在**[ nextTAMS, Top ]**之间，SATB能够确保这部分的对象都会被标记，默认都是存活的。
- 当并发标记结束时，将nextTAMS所在的地址赋值给previousTAMS，SATB给**[ Bottom, previousTAMS ]**之间的对象创建一个快照Bitmap，所有垃圾对象能通过快照被识别出来。
- 第n+1轮并发标记开始，过程和第n轮一样。
如下示意图显示了两轮并发标记的过程：
- A阶段，初始标记阶段，需要STW，将扫描Region的Top值赋值给nextTAMS。
- A-B阶段：并发标记阶段。
- B阶段，并发标记结束阶段，此时并发标记阶段生成的新对象都会被分配在[nextTAMS，Top]之间，这些对象会被定义为“隐式对象”，同时
_next_mark_bitmap也开始存储nextTAMS标记的对象的地址。 - C阶段，清除阶段，
_next_mark_bitmap和_prev_mark_bitmap会进行交换，同时清理**[ Bottom, previousTAMS ]**之间被标记的所有对象，对于“隐式对象”会在下次垃圾收集过程进行回收（如第F步），这也是SATB存在弊端，会一定程度产生未能在本次标记中识别的浮动垃圾。
3pre-write barrier解决对象引用被修改产生漏标的问题
千万不要把这个读屏障、写屏障和Java内存模型里面的读屏障搞混了，两者根本不是同一个东西，在G1中的写屏障，像是一种AOP技术，在字节码层面或者编译代码层面给写操作增加一个额外的处理。同理在ZGC中的读屏障也如此，在字节码层面或者编译代码层面给读操作增加一个额外的处理。
栅栏（屏障）是指在原生代码片段中，某些语句执行前，栅栏（屏障）代码也会执行。
G1主要是在写前栅栏（屏障）（pre-write barrier）和写后（屏障）（post-write barrier）。事实上，写栅栏的指令序列开销非常昂贵，应用吞吐量也会根据栅栏复杂度而降低。
-
pre-write barrier：在执行赋值时，等式左边引用会变更到另外一个对象上，这样原来等式右边对象将失去一个引用。那么G1的JVM会记录这个失去引用的对象。JVM并不会马上更新RSet，而是等批量操作，再将来更新RSet。
-
post-write barrier：在执行赋值后，等式右侧的对象将获得一个新的引用，这个对象所在region的RSet应该更新。为了提高性能，jvm也只是记录该更新日志，等后面批操作来更新RSet
Pre-Write Barrier和Post-Write Barrier 作用的对象不同，前者是针对三色标记算法的缺陷，后者是针对Card Table
SATB利用pre-write barrier，将所有即将被修改引用关系的白颜色对象旧引用记录下来，最后以这些旧引用为根重新扫描一遍，以解决白对象引用被修改产生的漏标问题。
在引用修改时把原引用保存到satb_mark_queue中，每个线程都自带一个satb_mark_queue。在下一次的并发标记阶段，会依次处理satb_mark_queue中的对象，确保这部分对象在本轮GC中是存活的。
如果被修改引用的白对象就是要被收集的垃圾，这次的标记会让它躲过GC，这就是float garbage。因为SATB的做法精度比较低，所以造成的float garbage也会比较多。
