参考链接： Python中的屏障对象Barrier Objects
什么是垃圾回收
曾几何时，内存管理是程序员开发应用的一大难题。传统的系统级编程语言（主要指C/C++）中，程序员必须对内存小心的进行管理操作，控制内存的申请及释放。稍有不慎，就可能产生内存泄露问题，这种问题不易发现并且难以定位，一直成为困扰开发者的噩梦。如何解决这个头疼的问题呢？过去一般采用两种办法：
内存泄露检测工具。这种工具的原理一般是静态代码扫描，通过扫描程序检测可能出现内存泄露的代码段。然而检测工具难免有疏漏和不足，只能起到辅助作用。智能指针。这是 c++ 中引入的自动内存管理方法，通过拥有自动内存管理功能的指针对象来引用对象，是程序员不用太关注内存的释放，而达到内存自动释放的目的。这种方法是采用最广泛的做法，但是对程序员有一定的学习成本（并非语言层面的原生支持），而且一旦有忘记使用的场景依然无法避免内存泄露。
为了解决这个问题，后来开发出来的几乎所有新语言（java，python，php等等）都引入了语言层面的自动内存管理 – 也就是语言的使用者只用关注内存的申请而不必关心内存的释放，内存释放由虚拟机（virtual machine）或运行时（runtime）来自动进行管理。而这种对不再使用的内存资源进行自动回收的行为就被称为垃圾回收。
常见垃圾回收（GC）算法
常见的 GC 算法有：
引用计数（reference counting）标记清除（mark & sweep）三色标记法节点复制（Copying Garbage Collection）分代收集（Generational Garbage Collection）
引用计数（reference counting）
这是最简单的一种垃圾回收算法，和之前提到的智能指针异曲同工。对每个对象维护一个引用计数，当引用该对象的对象被销毁或更新时被引用对象的引用计数自动减一，当被引用对象被创建或被赋值给其他对象时引用计数自动加一。当引用计数为0时则立即回收对象。引用计数是渐进式的，能够将内存管理的开销分布到整个程序之中。这种算法在内存比较紧张和实时性比较高的系统中使用的比较广泛。目前引用计数法主要用在 c++ 标准库的 std::shared_ptr 、微软的 COM 、Objective-C 和 PHP 中。 优点：
渐进式。内存管理与用户程序的执行交织在一起，将 GC 的代价分散到整个程序。不像标记-清扫算法需要 STW (Stop The World，GC 的时候挂起用户程序)。不过把业务代码与GC算法耦合在一起，GC会导致业务代码执行性能下降，变量指向变动越频繁，GC占用性能越高。算法实现相对简单内存单元能够很快被回收。相比于其他垃圾回收算法，堆被耗尽或者达到某个阈值才会进行垃圾回收。
缺点：
循环引用问题。当对象间发生循环引用时引用链中的对象都无法得到释放。最明显的解决办法是避免产生循环引用（比如强引用等），如cocoa引入了strong指针和weak指针两种指针类型。或者系统检测循环引用并主动打破循环链。当然这也增加了垃圾回收的复杂度。频繁更新引用计数降低了性能及运行效率。内存单元的更新删除等都需要维护相关的内存单元的引用计数，相比于一些追踪式的垃圾回收算法并不需要这些代价。一种简单的解决方法就是编译器将相邻的引用计数更新操作合并到一次更新；还有一种方法是针对频繁发生的临时变量引用不进行计数，而是在引用达到0时通过扫描堆栈确认是否还有临时对象引用而决定是否释放。
标记-清除（mark and sweep）
标记-清扫算法是第一种自动内存管理，基于追踪的垃圾收集算法。算法思想在 70 年代就提出了，是一种非常古老的算法。内存单元并不会在变成垃圾立刻回收，而是保持不可达状态，直到到达某个阈值或者固定时间长度。这个时候系统会挂起用户程序，也就是 STW（Stop The World），转而执行垃圾回收程序。垃圾回收程序对所有的存活单元进行一次全局遍历确定哪些单元可以回收。算法分两个部分：标记（mark）和清扫（sweep）。标记阶段表明所有的存活单元，清扫阶段将垃圾单元回收。 标记-清扫算法的优点也就是基于追踪的垃圾回收算法具有的优点：避免了引用计数算法的缺点（不能处理循环引用，需要维护指针）。但是这个算法也有一个缺陷，就是人们常常说的 STW 问题（Stop The World）。因为算法在标记时必须暂停整个程序，否则其他线程的代码可能会改变对象状态，从而可能把不应该回收的对象当做垃圾收集掉。 当程序中的对象逐渐增多时，递归遍历整个对象树会消耗很多的时间，在大型程序中这个时间可能会是毫秒级别的。让所有的用户等待几百毫秒的 GC 时间这是不能容忍的。golang 1.5以前使用的这个算法。 当然后续也出现了很多mark&sweep算法的变种（如三色标记法）优化了这个问题。
三色标记法
三色标记法是传统标记-清除（mark and sweep）的标记阶段的改进，它是一个并发的 GC 算法。 原理如下:
首先创建三个集合：白、灰、黑。将所有对象放入白色集合中。然后从根节点开始遍历所有对象（注意这里并不递归遍历），把遍历到的对象从白色集合放入灰色集合。之后遍历灰色集合，将灰色对象引用的对象从白色集合放入灰色集合，之后将此灰色对象放入黑色集合重复 4 直到灰色中无任何对象通过写屏障(Write Barrier)检测对象有变化，重复以上操作收集所有白色对象（垃圾） 这个算法可以实现 “on-the-fly”，也就是在程序执行的同时并发进行收集（mark阶段），并不需要暂停整个程序（后面会讲具体GC与业务代码怎么并发执行的，其实还是会有短暂的STW的）。 但是也会有一个缺陷，三色标记法是增量GC算法，可能程序中的垃圾产生的速度会大于垃圾收集的速度，这样会导致程序中的垃圾越来越多无法被收集掉。 使用这种算法的是 Go 1.5、Go 1.6。
节点复制（Copying Garbage Collection）
节点复制也是基于追踪的算法。其将整个堆等分为两个半区（semi-space），一个包含现有数据，另一个包含已被废弃的数据。节点复制式垃圾收集从切换（flip）两个半区的角色开始，然后收集器在老的半区，也就是 Fromspace 中遍历存活的数据结构，在第一次访问某个单元时把它复制到新半区，也就是 Tospace 中去。在 Fromspace 中所有存活单元都被访问过之后，收集器在 Tospace 中建立一个存活数据结构的副本，用户程序可以重新开始运行了。 优点：
所有存活的数据结构都缩并地排列在 Tospace 的底部，这样就不会存在内存碎片的问题。获取新内存可以简单地通过递增自由空间指针来实现。
缺点：
内存得不到充分利用，总有一半的内存空间处于浪费状态。
分代收集（Generational Garbage Collection）
基于追踪的垃圾回收算法（标记-清扫、节点复制）一个主要问题是在生命周期较长的对象上浪费时间（长生命周期的对象是不需要频繁扫描的）。同时，内存分配存在这么一个事实 “most object die young”。因此经过大量实际观察得知，在面向对象编程语言中，绝大多数对象的生命周期都很短，所以按照对象的生命周期长短来进行分代。分代收集算法也是传统 Mark-Sweep 的一个改进，将对象按生命周期长短存放到堆上的两个（或者更多）区域，这些区域就是分代（generation）。
新创建的对象存放在称为 新生代（young generation）中（一般来说，新生代的大小会比 老年代小很多），随着垃圾回收的重复执行，生命周期较长的对象会被提升（promotion）到老年代中。对于新生代的区域的垃圾回收频率要明显高于老年代区域。因此，新生代垃圾回收和老年代垃圾回收两种不同的垃圾回收方式应运而生，分别用于对各自空间中的对象执行垃圾回收。新生代垃圾回收的速度非常快，比老年代快几个数量级，即使新生代垃圾回收的频率更高，执行效率也仍然比老年代垃圾回收强，这是因为大多数对象的生命周期都很短，根本无需提升到老年代。
原理如下：
新对象放入第 0 代当内存用量超过一个较小的阈值时，触发 0 代收集第 0 代幸存的对象（未被收集）放入第 1 代只有当内存用量超过一个较高的阈值时，才会触发 1 代收集2 代同理 因为 0 代中的对象十分少，所以每次收集时遍历都会非常快（比 1 代收集快几个数量级）。只有内存消耗过于大的时候才会触发较慢的 1 代和 2 代收集。
因此，分代收集是目前比较好的垃圾回收方式。使用的语言（平台）有 jvm、.NET 。一般 GC 都会分三代，在 java 中称之为新生代（Young Generation）、年老代（Tenured Generation）和永久代（Permanent Generation）；在 .NET 中称之为第 0 代、第 1 代和第2代。
Golang的垃圾回收
golang的GC演变史
1.3版本以前，golang的垃圾回收算法是比较简陋的传统 Mark-Sweep 算法，其性能也广被诟病：go runtime在一定条件下（内存超过阈值或定期如2min），暂停所有任务的执行，进行mark&sweep操作，操作完成后启动所有任务的执行。在内存使用较多的场景下，go程序在进行垃圾回收时会发生非常明显的卡顿现象（Stop The World）。在对响应速度要求较高的后台服务进程中，这种延迟简直是不能忍受的！这个时期国内外很多在生产环境实践go语言的团队都或多或少踩过gc的坑。当时解决这个问题比较常用的方法是尽快控制自动分配内存的内存数量以减少gc负荷，同时采用手动管理内存的方法处理需要大量及高频分配内存的场景。1.3版本开始，go team开始对gc性能进行持续的改进和优化，主要是把 Sweep 改为了并行操作。每个新版本的go发布时gc改进都成为大家备受关注的要点。1.3版本中，go runtime分离了mark和sweep操作，和以前一样，也是先暂停所有任务执行并启动mark，mark完成后马上就重新启动被暂停的任务了，而是让sweep任务和普通协程任务一样并行的和其他任务一起执行。如果运行在多核处理器上，go会试图将gc任务放到单独的核心上运行而尽量不影响业务代码的执行。go team自己的说法是减少了50%-70%的暂停时间。1.4版本对gc的性能改动并不多。1.4版本中runtime很多代码取代了原生c语言实现而采用了go语言实现，对gc带来的一大改变是可以是实现精确的gc。c语言实现在gc时无法获取到内存的对象信息，因此无法准确区分普通变量和指针，只能将普通变量当做指针，如果碰巧这个普通变量指向的空间有其他对象，那这个对象就不会被回收。而go语言实现是完全知道对象的类型信息，在标记时只会遍历指针指向的对象，这样就避免了C实现时的堆内存浪费（解决约10-30%）。1.5版本go team对gc又进行了比较大的改进（1.4中已经埋下伏笔如write barrier的引入）,官方的主要目标是减少延迟。go 1.5正在实现的垃圾回收器是“非分代的、非移动的、并发的、三色的标记清除垃圾收集器”。分代算法上文已经提及，是一种比较好的垃圾回收管理策略，然1.5版本中并未考虑实现；我猜测的原因是步子不能迈太大，得逐步改进，go官方也表示会在1.6版本的gc优化中考虑。同时引入了上文介绍的三色标记法，这种方法的mark操作是可以渐进执行的而不需每次都扫描整个内存空间，可以减少stop the world的时间。从1.8以后的golang将第一步的stop the world 也取消了，这又是一次优化。1.9开始, 写屏障的实现使用了Hybrid Write Barrier, 大幅减少了第二次STW的时间。
golang的GC
root
首先标记root根对象，根对象的子对象也是存活的。 根对象包括：全局变量，各个G stack上的变量等。
标记
span是go内存管理的最小单位。 bitmap 如图所示，通过gcmarkBits位图标记span的块是否被引用。对应内存分配中的bitmap区。
三色标记
灰色：对象已被标记，但这个对象包含的子对象未标记黑色：对象已被标记，且这个对象包含的子对象也已标记，gcmarkBits对应的位为1（该对象不会在本次GC中被清理）白色：对象未被标记，gcmarkBits对应的位为0（该对象将会在本次GC中被清理）
例如，当前内存中有A~F一共6个对象，根对象a,b本身为栈上分配的局部变量，根对象a、b分别引用了对象A、B, 而B对象又引用了对象D，则GC开始前各对象的状态如下图所示:
初始状态下所有对象都是白色的。接着开始扫描根对象a、b; 由于根对象引用了对象A、B,那么A、B变为灰色对象，接下来就开始分析灰色对象，分析A时，A没有引用其他对象很快就转入黑色，B引用了D，则B转入黑色的同时还需要将D转为灰色，进行接下来的分析。灰色对象只有D，由于D没有引用其他对象，所以D转入黑色。标记过程结束最终，黑色的对象会被保留下来，白色对象会被回收掉。
STW
stop the world是gc的最大性能问题，对于gc而言，需要停止所有的内存变化，即停止所有的goroutine，等待gc结束之后才恢复。
Go垃圾回收触发方式
阈值：默认内存扩大一倍，启动gc定期：默认2min触发一次gc，src/runtime/proc.go:forcegcperiod手动：runtime.gc()
GC流程
GO的GC是并行GC, 也就是GC的大部分处理和普通的go代码是同时运行的, 这让GO的GC流程比较复杂.
Stack scan：Collect pointers from globals and goroutine stacks。收集根对象（全局变量，和G stack），开启写屏障。全局变量、开启写屏障需要STW，G stack只需要停止该G就好，时间比较少。Mark: Mark objects and follow pointers。标记所有根对象, 和根对象可以到达的所有对象不被回收。Mark Termination: Rescan globals/changed stack, finish mark。重新扫描全局变量，和上一轮改变的stack（写屏障），完成标记工作。这个过程需要STW。Sweep: 按标记结果清扫span
目前整个GC流程会进行两次STW(Stop The World), 第一次是Stack scan阶段, 第二次是Mark Termination阶段.
第一次STW会准备根对象的扫描, 启动写屏障(Write Barrier)和辅助GC(mutator assist).第二次STW会重新扫描部分根对象, 禁用写屏障(Write Barrier)和辅助GC(mutator assist).
从1.8以后的golang将第一步的stop the world 也取消了，这又是一次优化； 1.9开始, 写屏障的实现使用了Hybrid Write Barrier, 大幅减少了第二次STW的时间.
Go的STW时间降到微秒级 总的来说, 确实是牺牲了gc吞吐量换来了极短的stw, 这也是故意这样设计的: 一是go的主要应用领域不是CPU敏感的, 而是需要高开发效率甚于高性能的C语言替代品, 通常用于重度IO领域; 二是go避免了跟jvm和.net这样高吞吐量gc的正面竞争, 发挥出不可替代短stw能力.
写屏障
因为go支持并行GC, GC的扫描和go代码可以同时运行, 这样带来的问题是GC扫描的过程中go代码有可能改变了对象的依赖树。写屏障就是收集标记阶段对象依赖树修改记录的。
例如开始扫描时发现根对象A和B, B拥有C的指针。
GC先扫描A，A放入黑色B把C的指针交给AGC再扫描B，B放入黑色C在白色，会回收；但是A其实引用了C。
为了避免这个问题, go在GC的标记阶段会启用写屏障(Write Barrier)。
启用了写屏障(Write Barrier)后，在GC第三轮rescan阶段，根据写屏障标记将C放入灰色，防止C丢失。
注意
Go 除了标准的三色收集以外，还有一个辅助回收功能，防止垃圾产生过快收集不过来的情况。这部分代码在 runtime.gcAssistAlloc 中。 但是 golang 并没有分代收集，所以对于巨量的小对象还是很苦手的，会导致整个 mark 过程十分长，在某些极端情况下，甚至会导致 GC 线程占据 50% 以上的 CPU。 因此，当程序由于高并发等原因造成大量小对象的gc问题时，最好可以使用 sync.Pool 等对象池技术，避免大量小对象加大 GC 压力。
参考
Golang GC 垃圾回收机制详解 Golang 垃圾回收机制 golang垃圾回收
有疑问加站长微信联系（非本文作者）
