G1垃圾收集器

1.G1的目的：

Garbage First，也就是垃圾优先原则，也就是空间方面的关注点。同时照顾到停顿时间以及吞吐量。

G1垃圾收集器的设计目的是避免完全回收，但是当并发收集不能足够快地回收内存时，就会发生完全回收GC。G1的完整GC的当前实现使用单线程mark-sweep compact算法。

1.1JDK8为什么不用CMS做为默认垃圾收集器呢

1.CMS单线程或者双线程情况下效率很低

2.CMS会并发失败

3.CMS可中止的预处理会导致极限5S停顿

4.并发失败进入foregroud还会导致进入Full GC,全局MSC整理

5.CMS吞吐的设计并不是很优秀

1.2G1的特点:

内存空间的重新定义

更短的停顿时间，要多短就多短

某种程度上去解决空间碎片

2.内存空间的重新定义:region

G1的一个Region大小可以单独设定，可以1-32M，设置需要已2的n次幂来设置，因为很多算法都是已2的n次幂来计算的，所以Region大小也要按照这个来实现

G1虽然保留了新老年代的概念，但是G1把他们分成了一个一个的Region。

2.1Region的角色：

自由角色FreeTag

新生代分区 YoungHeapRegion，细分为eden分区和survivor分区

大对象分区 HHR，细分为大对象头分区和大对象连续分区

老年代分区 OHR

JDK11之后有一类特殊的分区，叫做归档分区，关闭归档分区以及开放归档分区

3.TLAB（线程本地分配缓冲区 Thread Local Allocation Buffer）

分配空间时，为了提高JVM的运行效率，应当尽量减少临界区范围，避免全局锁。G1的通常的应用场景中，会存在大量的访问器同时执行，为减少锁冲突，JVM引入了TLAB（线程本地分配缓冲区 Thread Local Allocation Buffer）机制。

3.1TLAB作用：

我们知道对象内存分配时最初考虑在新生代的Eden区为对象分配内存，但堆区是线程共享的区域，在多线程环境下多个线程同时操控同一块内存的现象是普遍的，为了保证对象分配时数据的安全性，我们需要用全局锁来解决多线程同时访问同一块内存的问题，但全局锁会降低效率与程序的吞吐量，为了解决该问题TLAB应运而生

在分配线程对象时，从JVM堆中分配一个固定大小的内存区域并将其作为线程的私有缓冲区，这个缓冲区称为TLAB。只有在为每个线程分配TLAB缓冲区时才需要锁定整个JVM堆。

由于TLAB是属于线程的，不同的线程不共享TLAB，当我们尝试分配一个对象时，优先从当前线程的TLAB中分配对象，不需要锁，因此达到了快速分配的目的。

实际上TLAB是Eden区域中的一块内存，不同线程的TLAB都位于Eden区，所有的TLAB内存对所有的线程都是可见的，只不过每个线程有一个TLAB的数据结构，用于保存待分配内存区间的起始地址（start）和结束地址（end），在分配的时候只在这个区间做分配，从而达到无锁分配，快速分配。

虽然TLAB在分配对象空间的时候是无锁分配，但是TLAB空间本身在分配的时候(分配TLAB内存空间)还是需要锁的，G1中使用了CAS来并行分配。

对象的分配实在TLAB中进行，由于每个线程都有一个独立的TLAB，所以可以达到无锁分配，如果失败了就会发生GC

3.2G1对新老年代中的相互引用是怎么处理的？

G1在进行oldGC的时候都会进行youngGC，所以不用管新生代指向老年代的问题

记录引用关系的2中方式

obj1=obj2

out:所有的引用关系都记录在obj1中，我引用了谁

in：所有的引用关系都记录在obj2，谁引用了我，G1使用的这种，但是如果位置不够怎么办，引用集

4.RSet（RemeberSet）引用集

4.1稀疏表

本质上就是一种Hash表，Key是Region的起始地址，Value是一个数组，里面存储的元素是卡页的索引号。将一个Region分成小块，每个小块都是V中的一个值

4.2粗粒度位图

当细粒度位图 size超过阈值时，所有region 形成一个 bitMap。如果有region 对当前 Region 有指针指向，就设置其对应的bit 为1，也就是粗粒度位图

一个位图对应一个Region

4.3细粒度位图

就是一个C位图，但是这个位图，可以详细的记录我们的内存变化，包括并发标记修改，对应元素标识等当稀疏表指定region的card数量超过阈值时，则在细粒度位图中创建一个对应的PerRegionTable对象。一个Region地址链表，维护当前Region中所有card对应的一个BitMap集合。

5.什么是写屏障：

因为Store Buffer导致读写的顺序不一致，而写屏障可以解决这个问题

多核情况下，cpu0与CPU1共享一个数据，如果0修改了数据那么就要将这个数据置为失效，并且通知1，还要等到1的回执才能继续执行，这样就会很慢，这时就加入了Store Buffer，先写入Store Buffer，等到收到AcKnowledgement的时候，再把数据刷入缓存，但是这个时候还有一个问题，写数据走了Store Buffer，如果读取的时候不走Store Buffer直接走cache，不就导致数据不一致了么，所以，读要同时走cache和Store Buffer

StoreBuffer，导致读写不一致

a的值可能因为是Share（共享）先被写入了Store Buffer，并发送通知其他cpu置为Invalid(失效)
b的值，可能因为在cache中已经存在并且是Exclusive（独占）直接被写进cache中。
读取的时候因为先读b的值，b被刷进主存供读取
后面要读a，因为还没收到失效通知，从cache中直接拿到a，断言失败。

5.1写屏障的内存伪共享问题：

如果不同线程对对象引用的更新操作，恰好位于同一个64KB区域内，这将导致同时更新卡表的同一个缓存行，从而造成缓存行的写回、无效化或者同步操作，间接影响程序性能。

5.2解决方案：

不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表项未被标记过才将其标记为dirty。这就是JDK 7中引入的解决方法，引入了一个新的JVM参数-XX:+UseCondCardMark，

6.G1的Rset同步异步问题：

异步更新操作需要引入DCQS（Dirty Card Queue Set）结构。

JVM声明了一个全局的静态结构G1BarrierSet，其中包含两个Queue Set，DirtyCardQueueSet和G1SATBMarkQueueSet，分别用于处理DCQS和STAB

G1常用参数： -XX: +UseG1GC 开启G1垃圾收集器 -XX: G1HeapReginSize 设置每个Region的大小，是2的幂次，1MB-32MB之间 -XX:MaxGCPauseMillis 最大停顿时间 -XX:ParallelGCThread 并行GC工作的线程数 -XX:ConcGCThreads 并发标记的线程数 -XX:InitiatingHeapOcccupancyPercent 默认45%，代表GC堆占用达到多少的时候开始垃圾收集

7.G1常用参数：

-XX: +UseG1GC 开启G1垃圾收集器

-XX: G1HeapReginSize 设置每个Region的大小，是2的幂次，1MB-32MB之间

-XX:MaxGCPauseMillis 最大停顿时间

-XX:ParallelGCThread 并行GC工作的线程数

-XX:ConcGCThreads 并发标记的线程数

-XX:InitiatingHeapOcccupancyPercent 默认45%，代表GC堆占用达到多少的时候开始垃圾收集