一、所谓的垃圾

垃圾：如果一个或多个对象没有任何的引用指向它了，那么这个对象现在就是垃圾

在堆里存放着几乎所有的 Java 对象实例，在 GC 执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC 才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程可以称为垃圾标记阶段，判断对象存活一般有两种方式：引用计数算法和可达性分析算法

二、引用计数器法

引用计数算法（Reference Counting）：对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加 1；当引用失效时，引用计数器就减 1；当对象 A 的引用计数器的值为 0，即表示对象A不可能再被使用，可进行回收（Java 没有采用）

优点：

回收没有延迟性，无需等到内存不够的时候才开始回收，运行时根据对象计数器是否为 0，可以直接回收
在垃圾回收过程中，应用无需挂起；如果申请内存时，内存不足，则立刻报 OOM 错误
区域性，更新对象的计数器时，只是影响到该对象，不会扫描全部对象

缺点：

每次对象被引用时，都需要去更新计数器，有一点时间开销
浪费 CPU 资源，即使内存够用，仍然在运行时进行计数器的统计。

无法解决循环引用问题，会引发内存泄露（最大的缺点）

public class Test {
    public Object instance = null;
    public static void main(String[] args) {
        Test a = new Test();// a = 1
        Test b = new Test();// b = 1
        a.instance = b;		// b = 2
        b.instance = a;		// a = 2
        a = null;			// a = 1
        b = null;			// b = 1
    }
}

在这里插入图片描述

三、可达性分析法

GC Roots

可达性分析算法：也可以称为根搜索算法、追踪性垃圾收集

GC Roots 对象：

虚拟机栈中局部变量表中引用的对象：各个线程被调用的方法中使用到的参数、局部变量等
本地方法栈中引用的对象
堆中类静态属性引用的对象
方法区中的常量引用的对象
字符串常量池（string Table）里的引用
同步锁 synchronized 持有的对象

GC Roots 是一组活跃的引用，不是对象，放在 GC Roots Set 集合

工作原理

可达性分析算法以根对象集合（GCRoots）为起始点，从上至下的方式搜索被根对象集合所连接的目标对象

分析工作必须在一个保障一致性的快照中进行，否则结果的准确性无法保证，这也是导致 GC 进行时必须 Stop The World 的一个原因

基本原理：

可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索走过的路径称为引用链
如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象
在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象

三色标记

标记算法

三色标记法把遍历对象图过程中遇到的对象，标记成以下三种颜色：

白色：尚未访问过
灰色：本对象已访问过，但是本对象引用到的其他对象尚未全部访问
黑色：本对象已访问过，而且本对象引用到的其他对象也全部访问完成

当 Stop The World (STW) 时，对象间的引用是不会发生变化的，可以轻松完成标记，遍历访问过程为：

初始时，所有对象都在白色集合
将 GC Roots 直接引用到的对象挪到灰色集合
从灰色集合中获取对象：
- 将本对象引用到的其他对象全部挪到灰色集合中
- 将本对象挪到黑色集合里面
重复步骤 3，直至灰色集合为空时结束
结束后，仍在白色集合的对象即为 GC Roots 不可达，可以进行回收

参考文章：https://www.jianshu.com/p/12544c0ad5c1

并发标记

并发标记时，对象间的引用可能发生变化，多标和漏标的情况就有可能发生

多标情况：当 E 变为灰色或黑色时，其他线程断开的 D 对 E 的引用，导致这部分对象仍会被标记为存活，本轮 GC 不会回收这部分内存，这部分本应该回收但是没有回收到的内存，被称之为浮动垃圾

针对并发标记开始后的新对象，通常的做法是直接全部当成黑色，也算浮动垃圾
浮动垃圾并不会影响应用程序的正确性，只是需要等到下一轮垃圾回收中才被清除

漏标情况：

条件一：灰色对象断开了对一个白色对象的引用（直接或间接），即灰色对象原成员变量的引用发生了变化
条件二：其他线程中修改了黑色对象，插入了一条或多条对该白色对象的新引用
结果：导致该白色对象当作垃圾被 GC，影响到了程序的正确性

代码角度解释漏标：

Object G = objE.fieldG; // 读
objE.fieldG = null;  	// 写
objD.fieldG = G;     	// 写

为了解决问题，可以操作上面三步，将对象 G 记录起来，然后作为灰色对象再进行遍历，比如放到一个特定的集合，等初始的 GC Roots 遍历完（并发标记），再遍历该集合（重新标记）

所以重新标记需要 STW，应用程序一直在运行，该集合可能会一直增加新的对象，导致永远都运行不完

解决方法：添加读写屏障，读屏障拦截第一步，写屏障拦截第二三步，在读写前后进行一些后置处理：

写屏障 + 增量更新：黑色对象新增引用，会将黑色对象变成灰色对象，最后对该节点重新扫描

增量更新 (Incremental Update) 破坏了条件二，从而保证了不会漏标

缺点：对黑色变灰的对象重新扫描所有引用，比较耗费时间
写屏障 (Store Barrier) + SATB：当原来成员变量的引用发生变化之前，记录下原来的引用对象

保留 GC 开始时的对象图，即原始快照 SATB，当 GC Roots 确定后，对象图就已经确定，那后续的标记也应该是按照这个时刻的对象图走，如果期间对白色对象有了新的引用会记录下来，并且将白色对象变灰（说明可达了，并且原始快照中本来就应该是灰色对象），最后重新扫描该对象的引用关系

SATB (Snapshot At The Beginning) 破坏了条件一，从而保证了不会漏标
读屏障 (Load Barrier)：破坏条件二，黑色对象引用白色对象的前提是获取到该对象，此时读屏障发挥作用

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