JVM之垃圾收集器与三色标记法

垃圾收集算法

如下图：

1.分代收集理论

根据对象存活生命周期的不同将内存分为几块：年轻代、老年代。根据两个年代的特点，选择不同的垃圾回收算法
年轻代：对象存活时间较短，90%的对象朝生夕死，所以年轻代可以选择复制算法，因为存活的对象比较少，垃圾回收过程中移动对象耗费时间比较短。
老年代：对象存活时间较长，不适合使用复制算法，存活对象比较多，垃圾回收中，移动对象次数比较多，没有额外的空间对它进行担保。所以选择“标记-清除”或者“标记-压缩”算法进行垃圾收集。
注意：“标记清除”或者“标记压缩”算法会比赋值算法慢10倍以上。

标记-复制算法

**它可以将内存分为大小相同的两块，每次只使用一块。当一块的内存使用完后，触发GC，将存活的对象复制到另一块内存中，然后把原来内存空间中的垃圾对象清理掉。**这样每次的内存回收都是对内存区间的一般进行回收。
如下图：

–可用内存只有一半，另一半内存总处于空闲状态、所以使用复制算法，对内存空间会造成浪费；

标记-清除算法

分为标记阶段和清除阶段；标记阶段使用可达性分析算法，从GCRoot触发遍历标记存活的对象。清除阶段回收所有未被标记的对象。比较简单、但
1. 效率问题（标记对象太多，效率低）
2. 空间问题（标记清除后，产生内存碎片）

标记-整理算法

分为标记阶段，整理阶段；
标记阶段使用可达性分析遍历标记存活对象。
整理阶段将存活对象向一端移动，然后清理掉端边界以外的内存；

垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

1.Serial收集器

开启：-XX:+UseSerialGC -XX:+UseSerialOldGC
串行收集器时最基本的垃圾收集器。是一个单线程的垃圾收集器。它不仅只使用一条垃圾收集线程去完成垃圾收集，而且在垃圾收集过程中必须暂停其他的工作线程，知道垃圾收回收结束；

串行垃圾收集器年轻代使用复制算法、老年代（Serial Old）使用标记整理算法。

Serial收集器没有线程上下文切换，可以获得很高的单线程手机效率；
Serial Old收集器是Serial收集器的老年代版本，同样也是单线程收集器。
用途：

1. 与Parallel Scavenge收集器搭配使用
2. 作为CMS收集器的后备方案；

2.Parallel Scavenge收集器

开启：
年轻代：-XX:+UseParallelGC
老年代：-XX:+UseParallelOldGC

是Serial收集器的多线程版本；使用多线程进行垃圾收集外，其余行为与Serial收集器类似；默认的收集线程数跟cpu核数相同；使用多线程进行垃圾收集会大大提高收集效率；

Parallel Scavenge收集器关注点是高吞吐量、高效率利用CPU。即运行用户代码时间/CPU总消耗时间的比值（垃圾收集时间+运行用户代码时间）；

1. 新生代使用复制算法；
2. 老年代使用标记-整理算法；
3. 进行垃圾回收时，会暂停用户线程（STW）；

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用所线程和“标记整理”算法。在注重吞吐量以及CPU资源的场合，可以优先使用Parallel收集器组合。
JDK8默认是用Parallel收集器组合；

3.ParNew收集器

开启
XX:+UseParNewGC
ParNew收集器跟Parallel收集器类似，区别主要在于他可以和CMS收集器搭配使用；

1. 使用多线程进行垃圾收集
2. 使用复制算法
3. 垃圾收集时，需要暂停其他的工作线程（STW）；
   
   它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收 集器，后面会介绍到）配合工作。

4.CMS收集器

CMS是一种获取最短停顿时间为目标的垃圾收集器；注重用户体验；真正意义上的并发收集器，实现了工作线程与垃圾工作线程的同时工作；

1. 并发收集
2. 老年代使用标记-清除算法
3. 停顿时间STW很短；

工作流程：

1. 初始标记
   暂停所有工作线程，记录GCRoot直接能引用的对象，速度快，暂停时间段；
2. 并发标记
   从GCRoot开始遍历整个对象图的过程，这个过程耗时长但是不需要暂停工作线程，可以与垃圾收集线程并发运行。因为用户程序继续运行，可能导致已经标记过的对象状态发生变化
3. 重新标记
   修改并发标记期间因为用户程序运行而导致标记发生变动的那一部分对象的标记记录。这个阶段暂停其他的工作线程，但是暂停时间远比并发标记时间段。主要用到三色标记里的增量更新算法做重新标记；
4. 并发清理
   开启工作线程、同时GC线程开始对未标记的区域进行清理。这个阶段如果有新增对象会被标记为黑色，不做任何处理。
5. 并发重置
   重置本地GC过程中的标记数据。

主要优点：并发收集、低停顿。
主要缺点：

1. 对CPU资源敏感，会和工作线程争抢
2. 无法处理浮动垃圾（并发标记和并发清理阶段新产生的垃圾），只能等到下一次GC清理；
3. 会产生内存碎片。
4. 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记与并发清理阶段，一边回收一般运行，还没回收完就再次触发Full GC，也就是"concurrent mode failure"。此时会使用后备Serial Old垃圾收集器进行回收，会暂停所有工作线程且单线程回收，停顿时间很长。

CMS的相关核心参数

1 -XX:+UseConcMarkSweepGC：启用cms
2 -XX:ConcGCThreads：并发的GC线程数
3 -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
4 -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一 次
5 -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
6 -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设 定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
7 -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
8 -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
9 -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

三色标记法

在并发标记过程中，因为标记期间应用程序还在运行，对象间的引用可能发生变化，多标和漏标的情况可能发生。
三色标记：把GCRoots可达性分析遍历对象中遇到的对象，按照“是否访问过”标记成以下三种颜色。

• 黑色：如果对象已经被垃圾收集器访问过，且这个对象的所有引用都已经被扫描过。黑色的对象代表已经扫描过，是安全存活的，如果有其他对象引用指向了黑色对象，无需重新扫描一遍。
  黑色对象不可能直接指向某个白色对象。
• 灰色：对象已经被垃圾收集器访问过，但是这个对象至少存在一个引用还没有被扫描过。
• 白色：对象还没有被垃圾收集器访问过。可达性分析开始，所有对象都是白色的，如果分析结束，对象还是白色，代表不可达

多标-浮动垃圾

在并发标记过程，如果方法运行结束，导致部分局部变量（GCRoot）被销毁，这个GCRoot引用的对象之前又被扫描过（被标记为非垃圾对象），那么本轮GC不会回收这部分内存。这部分应该会回收但是没有会受到的内存，称为“浮动垃圾”。
浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

针对并发标记期间（或者并发清理）开始后新产生的对象，通常做法是直接标记为黑色。
本轮不会进行清除，这部分对象在GC期间可能变为垃圾，也是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致被引用的对象被当做垃圾误删除，这是严重bug,必须解决。有两种方案：增量更新、原始快照（SATB）

1. 增量更新就是当黑色对象插入新的指向白色对象的引用关系，就将这个新插入的引用记录下来。等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。
   即：黑色对象一旦新插入了指向白色对象的引用之后，就变为了灰色对象。

2. 原始快照就是当灰色对象要删除指向白色对象的引用关系时，将这个要删除的引用记录下来，在并发扫描结束后，在将这些记录过的引用关系中的灰色对象为根，就能扫描到白色对象，将白色对象直接标记为黑色（目的就是在本轮GC里活下来，不管是不是垃圾，宁愿不删，也不可错删，等待下一轮GC重新扫描，这个对象可能是浮动垃圾）。

以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过写屏障实现的。

写屏障

给某个对象的成员变量赋值时，其底层代码大概长这样：

void oop_field_store(oop* field, oop new_value) { 
 *field = new_value; // 赋值操作 
}

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（类似AOP）

void oop_field_store(oop* field, oop new_value) { 
 pre_write_barrier(field); // 写屏障‐写前操作 
 *field = new_value; post_write_barrier(field, value); // 写屏障写后操作
}

写屏障实现SATB

当对象B的成员变量的引用发生变化时，比如引用消失（= null），我们可以利用写屏障，将B原来成员变量的引用 对象D记录下来：

 void pre_write_barrier(oop* field) {
    // 1. 获取旧值 
    oop old_value = *field;
   // 2. 记录原来的引用对象 
    remark_set.add(old_value);
 }

需要在方法引用置空前，将旧值存下来。

写屏障实现增量更新

当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D 记录下来：

void post_write_barrier(oop* field, oop new_value) { 
remark_set.add(new_value); // 记录新引用的对象 
}

读屏障

在并发标记期间，当当读取成员变量时，一律记录下来。

对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：

1. CMS：写屏障 + 增量更新
2. G1，Shenandoah：写屏障 + SATB
3. ZGC：读屏障

为什么G1用SATB？CMS用增量更新？

G1使用的场景是32G或者更大，如果使用增量更新，每次都去遍历每一块region，由于内存大，耗费时间很长，且G1回收只会回收价值列表里价值较大的，如果遍历的region价值小，不会被回收，遍历了也没用，反正region不会被回收，也就不存在误删情况。所以使用SATB将白色对象标记为黑色，等待下一次GC再深度扫描。
CMS：适用于4-8G内存，且CMS就一块老年代区域，重新深度扫描对象的代价小于G1。

记忆集与卡表

在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。 为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个 老年代加入GCRoots扫描范围。事实上并不只是新生代、 老年代之间才有跨代引用的问题， 所有涉及部分区域收集 （Partial GC） 行为的垃圾收集器， 典型的如G1、 ZGC和Shenandoah收集器， 都会面临相同的问题。
垃圾收集场景中，收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨代引 用指针的全部细节。 hotspot使用一种叫做“卡表”(cardtable)的方式实现记忆集，也是目前最常用的一种方式。关于卡表与记忆集的关系， 可以类比为Java语言中HashMap与Map的关系。
卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡 页”。 hotSpot使用的卡页是2^9大小，即512字节

一个卡页中可包含多个对象，只要有一个对象的字段存在跨代指针，其对应的卡表的元素标识就变成1，表示该元素变 脏，否则为0. GC时，只要筛选本收集区的卡表中变脏的元素加入GCRoots里。

卡表的维护

卡表变脏上面已经说了，但是需要知道如何让卡表变脏，即发生引用字段赋值时，如何更新卡表对应的标识为1。 Hotspot使用写屏障维护卡表状态。