G1（Garbage First）算法，通过参数-XX:+UseG1GC来启用，该算法在JDK 7u4版本被正式推出,G1可以通过参数-XX:MaxGCPauseMillis控制GC暂停时间。
在G1算法中，采用了另外一种完全不同的方式组织堆内存，堆内存被划分为多个大小相等的内存块（Region），每个Region是逻辑连续的一段内存，结构如下：
每个Region被标记了E、S、O和H，说明每个Region在运行时都充当了一种角色，其中H是以往算法中没有的，它代表Humongous，这表示这些Region存储的是巨型对象（humongous object，H-obj），当新建对象大小超过Region大小一半时，直接在新的一个或多个连续Region中分配，并标记为H。
堆内存中一个Region的大小可以通过-XX:G1HeapRegionSize参数指定，大小区间只能是1M、2M、4M、8M、16M和32M，总之是2的幂次方，默认把堆内存按照2048份均分，也就是默认2048个Region。比如-Xmx16g -Xms16g，G1就会采用16G / 2048 = 8M 的Region。
G1中提供了三种模式垃圾回收模式，Young gc、Mixed gc 和 Full gc，在不同的条件下被触发。
发生在年轻代的GC算法，一般对象（除了巨型对象）都是在eden region中分配内存，当所有eden region被耗尽无法申请内存时，就会触发一次young gc，这种触发机制和之前的young gc差不多，执行完一次young gc，活跃对象会被拷贝到survivor region或者晋升到old region中。
年轻代，默认占用堆大小由以下参数控制：
当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即mixed gc，该算法并不是一个old gc，除了回收整个young region，还会回收一部分的old region，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些old region进行收集，一般是选择回收效益最高的，也就是垃圾最多的region，从而可以对垃圾回收的耗时时间进行控制。
mixed gc中也有一个阈值参数 -XX:InitiatingHeapOccupancyPercent，当老年代大小占整个堆大小百分比达到该阈值时，会触发一次mixed gc.
如果对象内存分配速度过快，mixed gc来不及回收，导致老年代被填满，就会触发一次full gc，G1的full gc算法就是单线程执行的serial old gc，会导致异常长时间的暂停时间，需要进行不断的调优，尽可能的避免full gc.
由于堆内存是应用程序共享的，应用程序的多个线程在分配内存的时候需要加锁以进行同步。为了避免加锁，提高性能每一个应用程序的线程会被分配一个TLAB。TLAB中的内存来自于G1年轻代中的内存分段。当对象不是Humongous对象，TLAB也能装的下的时候，对象会被优先分配于创建此对象的线程的TLAB中。这样分配会很快，因为TLAB隶属于线程，所以不需要加锁。当TLAB的剩余空间不满足分配需求，则重新申请一块TLAB空间。
1、很小的内存区域，G1将Java堆划分为相等大小的一个个区域，这个小的区域大小是512 Byte，称为Card
2、Card Table维护着所有的Card。Card Table的结构是一个字节数组，Card Table用这个数组映射着每一个Card
3、Card中对象的引用发生改变时，Card在Card Table数组中对应的值被标记为dirty，就称这个Card被脏化了
4、分配对象会占用物理上连续若干个卡片
1、每个Region初始化时，会初始化一个remembered set
2、RSet里面记录了引用——就是其他Region中指向本Region中所有对象的所有引用，也就是谁引用了我的对象即RSet需要记录的东西应该是 xx Region的 xx Card。
3、RSet其实是一个Hash Table，Key是其他的Region的起始地址，Value是一个集合，里面的元素是Card Table 数组中的index，既Card对应的Index，映射到对象的Card地址。
Region1和Region3中有对象引用了Region2的对象，则在Region2的Rset中记录了这些引用。
为了维护这些RSet，如果每次给引用类型的字段赋值都要更新RSet，这带来的额外开销实在太大，G1中采用post-write barrier（写后栅栏）和concurrent refinement threads（并发后台线程）实现了RSet的更新。
//假设对象young和old分别在不同的Region中
Object young = new Object();
old.p = young;Java层面给old对象的p字段赋值young对象的前后，JVM会插入一个pre-write barrier（写前栅栏）和post-write barrier（写后栅栏）。
1、写前栅栏 Pre-Write Barrrier：即将执行一段赋值语句时，等式左侧对象将修改引用到另一个对象，那么JVM就需要在赋值语句生效之前，记录丧失引用的对象。
2、写后栅栏 Post-Write Barrrier：当执行一段赋值语句后，等式右侧对象获取了左侧对象的引用，同样需要记录
其中post-write barrier的最终动作如下：
1、找到该字段所在的位置(Card)，并设置为dirty_card
2、如果当前是应用线程，每个Java线程有一个dirty card queue，把该card插入队列
3、除了每个线程自带的dirty card queue，还有一个全局共享的queue
赋值动作到此结束，接下来的RSet更新操作交由多个ConcurrentG1RefineThread并发完成，每当全局队列集合超过一定阈值后，ConcurrentG1RefineThread会取出若干个队列，遍历每个队列中记录的card，并进行处理，逻辑如下：
1、根据card的地址，计算出card所在的Region
2、如果Region不存在，或者Region是Young区，或者该Region在回收集合（CSet）中，则不进行处理
3、处理该card中的对象，将应用关系写入Rset中。
RSet有什么好处？
进行垃圾回收时，如果Region1有根对象A引用了Region2的对象B，显然对象B是活的，如果没有Rset，就需要扫描整个Region1或者其它Region，才能确定对象B是活跃的，有了Rset可以避免对整个堆进行扫描。
1、它记录了GC要收集的Regions集合
2、在任意一次收集暂停中，CSet所有分区都会被释放，内部存活的对象都会被转移到分配的空闲Region中。
3、CSet包括需要收集的Eden Regions、Survivor Regions，而且还包括部分(1/8)Old Regions（混合收集的时候，收集年轻代的时候，会收集一部分老年代的Region）。
为了解决在并发标记过程中，存活对象漏标的情况，GC HandBook把对象分成三种颜色：
1、黑色：自身以及可达对象都已经被标记
2、灰色：自身被标记，可达对象还未标记
3、白色：还未被标记
所以，漏标的情况只会发生在白色对象中，且满足以下任意一个条件：
1、并发标记时，应用线程给一个黑色对象的引用类型字段赋值了该白色对象
2、并发标记时，应用线程删除所有灰色对象到该白色对象的引用
对于第一种情况，利用post-write barrier，记录所有新增的引用关系，然后根据这些引用关系为根重新扫描一遍
对于第二种情况，利用pre-write barrier，将所有即将被删除的引用关系的旧引用记录下来，最后以这些旧引用为根重新扫描一遍
1、SATB是增量式标记清除垃圾收集器设计的一个标记算法。
2、SATB的标记优化主要针对标记-清除垃圾收集器的并发标记阶段。
3、CMS的i设计使得它在remark阶段必须重新扫描所有线程栈和整个young gen作为root。G1的SATB设计在remark阶段则只需要扫描剩下的satb_mark_queue。
1、SATB保证了在并发标记过程中新分配对象不会漏标。
2、SATB中的stab_mark_queue，在引用关系发生变化时，利用pre-write barrier，把原引用保存到stab_mark_queue中，每个应用线程都有一个stab_mark_queue。
SATB的算法，每个region有5个指针，比较复杂，没有找到太好的文章，没有太理解，还有待进一步了解~~~
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
