1、Go 1.3之前的标记-清除（mark and sweep）算法
Go 1.3之前的时候主要用的是普通的标记-清除算法，此算法主要由两个主要的步骤：
- 标记（Mark phase）
- 清除（Sweep phase）
1）、标记-清除算法的具体步骤
第一步，暂停程序业务逻辑，分类出可达和不可达的对象，然后做上标记
图中表示是程序与对象的可达关系，目前程序的可达对象有对象1->2->3，对象4->7等五个对象
第二步，开始标记，程序找出它所有可达的对象，并做上标记
对象1->2->3、对象4->7等五个对象被做上标记
第三步，标记完了之后，然后开始清除未标记的对象
操作非常简单，但是有一点需要额外注意：mark and sweep算法在执行的时候，需要程序暂停，即STW（stop the world）。STW的过程中，CPU不执行用户代码，全部用于垃圾回收，这个过程影响很大，所以STW也是一些回收机制最大的难题和希望优化的点。所以在执行第三步的这段时间，程序会暂停任何工作，卡在那等待回收执行完毕
第四步，停止暂停，让程序继续运行，然后重复这个过程，直到进程生命周期结束
2）、标记-清除的缺点
标记-清除算法明了，过程鲜明干脆，但是也有非常严重的问题
- STW让程序暂停，程序出现卡顿（重要问题）
- 标记需要扫描整个heap
- 清除数据会产生heap碎片
Go 1.3版本之前就是以上来实施的，在执行GC的基本流程就是首先启动STW暂停，然后执行标记，再执行数据回收，最后停止STW
从上图来看，全部的GC时间都是包裹在STW范围之内的，这样貌似程序暂停的时间过长，影响程序的运行性能。所以Go 1.3做了简单的优化，将STW的步骤提前，减少STW暂停的时间范围
上图主要是将STW的步骤提前了一步，因为在sweep清除的时候，可以不需要STW停止，因为这些对象已经是不可达对象了，不会出现回收写冲突等问题
但是无论怎么优化，Go 1.3都面临这个一个重要问题，就是标记-清除算法会暂停整个程序
2、Go 1.5的三色并发标记法
Go中的垃圾回收主要应用三色标记法，GC过程和其他用户goroutine可并发运行，但需要一定时间的STW，所谓三色标记法实际上就是通过三个阶段的标记来确定清除的对象都有哪些
1）、三色标记法的过程
第一步，每次新创建的对象，默认的颜色都是标记为白色
如上图所示，左边为程序可抵达的内存对象关系，右边的标记表用来记录目前每个对象的标记颜色分类。这里需要注意的是，所谓程序则是一些对象的根结点集合。所以我们如果将程序展开，会得到类似如下图的表现形式
第二步，每次GC回收开始，会从根节点开始遍历所有对象，把遍历到的对象从白色集合放入灰色集合
这里要注意的是，本次遍历是一次遍历，非递归形式，是从程序抽出可抵达的对象遍历一层，如上图所示，当前可抵达的对象是对象1和对象4，那么自然本轮遍历结束，对象1和对象4就会被标记为灰色，灰色标记表就会多出这两个对象
第三步，遍历灰色集合，将灰色对象引用的对象从白色集合放入灰色集合，之后将此灰色对象放入黑色集合
这一次遍历是只扫描灰色对象，将灰色对象的第一层遍历可抵达的对象由白色变为灰色，如对象2、对象7。而之前的灰色对象1和对象4则会被标记为黑色，同时由灰色标记表移动到黑色标记表中
第四步，重复第三步，直到灰色中无任何对象
当全部的可达对象都遍历完后，灰色标记表将不再存在灰色对象，目前全部内存的数据只有两种颜色，黑色和白色。那么黑色对象就是我们程序逻辑可达（需要的）对象，这些数据是目前支撑程序正常业务运行的，是合法的有用数据，不可删除，白色的对象是全部不可达对象，目前程序逻辑并不依赖它们，那么白色对象就是内存中目前的垃圾数据，需要被清除
第五步，回收所有的白色标记表的对象，也就是垃圾回收
将全部的白色对象进行删除回收，剩下的就是全部依赖的黑色对象
以上便是三色并发标记法，不难看出，上面已经清楚的体现三色的特性。但是这里面可能会有很多并发流程均会被扫描，执行并发流程的内存可能相互依赖，为了在GC过程中保证数据的安全，我们在开始三色标记之前就会加上STW，在扫描确定黑白对象之后再放开STW。但是很明显这样的GC扫描的性能实在是太低了
2）、没有STW的三色标记法
假设没有STW，那么也就不会再存在性能上的问题。那么接下来假设如果三色标记法不加入STW会发生什么事情？
当前已经经历了第一轮扫描，目前黑色的有对象1和对象4，灰色的有对象2和对象7，其他的为白色对象，且对象2是通过指针p指向对象3的，如下图所示：
现在如果三色标记过程不启动STW，那么在GC扫描过程中，任意的对象均可能发生读写操作，如下图所示，在还没有扫描到对象2的时候，已经标记为黑色的对象4，此时创建指针q，并且指向白色的对象3
与此同时灰色的对象2将指针p移除，那么白色的对象3实则就是被挂在了已经扫描完成的黑色的对象4下，如下图所示：
然后正常执行三色标记的算法逻辑，将所有灰色的对象标记为黑色，那么对象2和对象7就被标记为了黑色，如下图所示：
那么就执行了三色标记的最后一步，将所有白色对象当做垃圾进行回收，如下图所示：
但是本来是对象4合法引用的对象3却被GC给误杀回收掉了
3）、触发三色标记法不安全的必要条件
可以看出，有两种情况在三色标记法中是不希望被发生的
- 条件1：一个白色对象被黑色对象引用（白色被挂在黑色下）
- 条件2：灰色对象与它之间的可达关系的白色对象遭到破坏（灰色同时丢了该白色）
如果当以上两个条件同时满足时，就会出现对象丢失现象
并且，如图所示的场景中，如果示例的白色对象3还有很多下游对象的恶化，也会一并都清理掉
为了防止这种现象的发生，最简单的方式就是STW，直接禁止掉其他用户程序对对象引用关系的干扰，但是STW的过程有明显的资源浪费，对所有的用户程序都有很大影响。那么是否可以在保证对象不丢失的情况下合理的尽可能的提高GC效率，减少STW时间呢？答案是可以的，只要使用一种机制，尝试去破坏上面的两个必要条件就可以了
3、屏障机制
让GC回收器满足下面两种情况之一时，即可保证对象不丢失。这两种方式就是强三色不变式和弱三色不变式
1）、强弱三色不变式
强三色不变式：
不存在黑色对象引用到白色对象的指针
强三色不变式实际上是强制性的不允许黑色对象引用白色对象，这样就不会出现有白色对象被误删的情况
弱三色不变式：
所有被黑色对象引用的白色对象都处于灰色保护状态
弱三色不变式强调，黑色对象可以引用白色对象，但是这个白色对象必须存在其他灰色对象对它的引用，或者可达它的链路上游存在灰色对象。这样实则是黑色对象引用白色对象，白色对象处于一个危险被删除的状态，但是上游灰色对象的引用，可以保护该白色对象，使其安全
为了遵循上述的两个方式，GC算法演进到两种屏障方式：插入屏障、删除屏障
2）、插入屏障
具体操作：在A对象引用B对象的时候，B对象被标记为灰色（将B挂在A下游，B必须被标记为灰色）
满足：强三色不变式（不存在黑色对象引用到白色对象的情况了，因为白色会强制变为灰色）
伪代码：
添加下游对象(当前下游对象slot, 新下游对象ptr) {
// 1
标记灰色(新下游对象ptr)
// 2
当前下游对象slot = 新下游对象ptr
}
场景：
A.添加下游对象(nil, B) // A之前没有下游,新添加一个下游对象B,B被标记为灰色
A.添加下游对象(C, B) // A将下游对象C更换为B,B被标记为灰色
这段伪代码逻辑就是写屏障。黑色对象的内存槽有两种位置，栈和堆。栈空间的特点是容量小，但是要求响应速度快，因为函数调用弹出频繁使用，所以插入屏障机制在栈空间的对象操作中不使用，而仅仅使用在堆空间对象的操作中
但是如果栈不添加，当全部三色标记扫描之后，栈上有可能依然存在白色对象被引用的情况（如上图的对象9）。所以要对栈重新进行三色标记扫描，但这次为了对象不丢失，要对本次扫描启动STW暂停，直到栈空间的三色标记结束
最后将栈和堆空间扫描剩余的全部白色节点清除。这次STW大约的时间在10-100ms间
3）、删除屏障
具体操作：被删除的对象，如果自身为灰色或者白色，那么被标记为灰色
满足：弱三色不变式（保护灰色对象到白色对象的路径不会断）
伪代码：
添加下游对象(当前下游对象slot， 新下游对象ptr) {
// 1
if (当前下游对象slot是灰色 || 当前下游对象slot是白色) {
标记灰色(当前下游对象slot) // slot为被删除对象,标记为灰色
}
// 2
当前下游对象slot = 新下游对象ptr
}
场景：
A.添加下游对象(B, nil) // A对象删除B对象的引用.B被A删除,被标记为灰(如果B之前为白)
A.添加下游对象(B, C) // A对象更换下游B变成C.B被A删除,被标记为灰(如果B之前为白)
这种方式的回收精度低，一个对象即使被删除了最后一个指向它的指针也依旧可以活过这一轮，在下一轮GC中被清理掉
4、Go 1.8的混合写屏障（hybrid write barrier）机制
插入屏障和删除屏障的短板：
- 插入屏障：结束时需要STW来重新扫描栈，标记栈上引用的白色对象的存活
- 删除屏障：回收精度低，GC开始时STW扫描堆栈来记录初始快照，这个过程会保护开始时刻的所有存活对象
Go 1.8版本引入了混合写屏障机制（hybrid write barrier），避免了对栈re-scan的过程，极大的减少了STW的时间，结合了两者的优点
1）、混合写屏障规则
具体操作：
- GC开始将栈上的对象全部扫描并标记为黑色（之后不再进行第二次重复扫描，无需STW）
- GC期间，任何在栈上创建的新对象均为黑色
- 堆上被删除的对象标记为灰色
- 堆上被添加的对象标记为灰色
混合写屏障实际上满足的是一种变形的弱三色不变式。它的伪代码如下：
添加下游对象(当前下游对象slot, 新下游对象ptr) {
// 1
标记灰色(当前下游对象slot) // 只要当前下游对象被移走，就标记灰色
// 2
标记灰色(新下游对象ptr)
// 3
当前下游对象slot = 新下游对象ptr
}
注意：屏障技术不在栈上应用，因为要保证栈的运行效率。混合写屏障是GC的一种屏障机制，所以只是当程序执行GC的时候，才会触发这种机制
2）、混合写屏障的具体场景分析
1）GC开始：扫描栈区，将可达对象全部标记为黑
2）场景一： 对象被一个堆对象删除引用，成为栈对象的下游
场景1主要描述的是对象被堆对象删除引用，成为栈对象的下游情况，伪代码如下：
// 前提:堆对象4->对象7 = 对象7; // 对象7被对象4引用
栈对象1->对象7 = 堆对象7; // 将堆对象7挂在栈对象1下游
堆对象4->对象7 = null; // 对象4删除引用对象7
3）场景二： 对象被一个栈对象删除引用，成为另一个栈对象的下游
场景2主要描述的是对象被一个栈对象删除引用，成为另一个栈对象的下游情况，伪代码如下：
new 栈对象9;
对象8->对象3 = 对象3; // 将栈对象3挂在栈对象9下游
对象2->对象3 = null; // 对象2删除引用对象3
4）场景三：对象被一个堆对象删除引用，成为另一个堆对象的下游
场景3主要描述的是对象被一个堆对象删除引用，成为另一个堆对象下游的情况，伪代码如下：
堆对象10->对象7 = 堆对象7; // 将堆对象7挂在堆对象10下游
堆对象4->对象7 = null; // 对象4删除引用对象7
5）场景四：对象从一个栈对象删除引用，成为另一个堆对象的下游
场景4主要描述的是对象从一个栈对象被删除引用，成为另一个堆对象的下游情况，伪代码如下：
堆对象10->对象7 = 堆对象7; // 将堆对象7挂在堆对象10下游
堆对象4->对象7 = null; // 对象4删除引用对象7
Go中的混合写屏障满足弱三色不变式，结合了删除屏障和插入屏障的优点，只需要在开始时并发扫描各个goroutine的栈，使其变黑并一直保持，这个过程不需要STW，而标记结束后，因为栈在扫描后始终是黑色的，也无需再进行re-scan操作了，减少了STW的时间
6、小结
Go 1.3使用普通标记清除法，整体过程需要启动STW，效率极低
Go 1.5使用三色标记法， 堆空间启动写屏障，栈空间不启动，全部扫描之后，需要重新扫描一次栈（需要STW），效率普通
Go 1.8使用三色标记法，混合写屏障机制， 栈空间不启动，堆空间启动。整个过程几乎不需要STW，效率较高
参考：
Golang三色标记混合写屏障GC模式全分析
