也便是说，GC是一个过程，而golang gc是一个垃圾回收器，是一个程序组件，当然，还有很多问题没有得到答案，我就考试测验着带着问题，去寻求答案，逐步的去理解和剖析golang gc。
什么是垃圾？现实中：你开着汽车行驶在马路上，吃完东西后丢出的剩余包装袋，是垃圾；你随地丢下的烟头是垃圾；但是你丢下的钱包或许不应该归类为垃圾。程序中：程序运行过程中，会不断的创建工具，当程序运行过程中或完结后，已经确定不会再次利用的，还占用着内存的工具是垃圾。为什么须要回收？现实中：1、人们在生活中会产生垃圾，并且会有人随处遗留下垃圾。2、我们须要一个干净的马路，不然会导致很多由于垃圾产生的问题（环保问题，行车安全....)。程序中：1、程序运行周期内，会不断的创建工具，，创建工具的时候须要分配内存空间来存储这些工具。2、很多的工具的生命周期并不长，远远小于程序本身的运行韶光。3、由于内存空间是有限的，如果我们不去回收已经不被利用的工具所占用的空间，会导致程序可利用的内存空间不断减少或没有空间可用。谁来回收？现实中：自然是环卫师傅，骑着小电车，手里拿着小夹子，来回穿梭在城市的角落。程序中：自然便是本文谈论的这个Golang GC模块来完成这些操作。如何回收？现实中：1、环卫师傅每次骑着小电车，来回穿梭在他所统领的区域内。2、他会不断地用眼睛扫描统领区域内的每个角落，通过眼睛和大脑，给所见的每一件事物打上标记（花草树木，路边的行人，行驶的轿车，散落的烟头，揉成一坨的纸巾）3、他会在标识的事务中标记出垃圾。4、用随身携带的工具把垃圾拾起放入垃圾车里面。5、如果垃圾相对而言还有代价（塑料瓶，纸壳...）,则会被放入一个专属的小袋子中，供应个下一个流程（***，二次利用）。程序大致也是如此，不过程序中的垃圾都是须要二次利用的：1、makr(标记)识别垃圾2、sweep(垃圾销毁)3、垃圾回收到可用内存管理链表上（freelist）
优点： 1、引用计数法可以在工具不生动时（引用计数为0）急速回收其内存。因此可以担保堆上时时刻刻都没有垃圾工具的存在（先不考虑循环引用导致无法回收的情形）。 2、引用计数法的最大停息韶光短。由于没有了独立的GC过程，而且不须要遍历全体堆来标记和打消工具，取而代之的是在工具引用计数为0时立即回收工具，这相称于将GC过程“分摊”到了每个工具上，不会有最大停息韶光特殊长的情形发生。
劣势：
引用计数的增减开销在一些情形下会比较大，比如一些根引用的指针更新非常频繁，此时这种开销是不能忽略的。其余工具引用计数器本身是须要空间的，而计数器要占用多少位也是一个问题，理论上系统内存可寻址的范围越大，工具计数器占用的空间就要越大，这样在一些小工具上就会涌现计数器空间比工具本身的域还要大的情形，内存空间利用率就会降落。还有一个问题是循环引用的问题，假设两个工具A和B，A引用B，B也引用A，除此之外它们都没有其他引用关系了，这个时候A和B就形成了循环引用，变成一个“孤岛”，且它们的引用计数都是1，按照引用计数法的哀求，它们将无法被回收，造成内存泄露。追踪式优点：
相对付引用计数算法，完备不必考虑环形引用问题。操纵指针时没有额外的开销。与用户程序完备分离。缺陷：
标记清扫算法是非实时的，它哀求在垃圾网络器运行时停息用户程序运行，这对付实时和交互式系统的影响非常大。基本的标记清扫算法常日在回收内存时会同时合并相邻空闲内存块，然而在系统运行一段韶光后仍旧难免会天生大量内存碎片，内存碎片意味着可用内存的总数量上足够但实际上不可用，同时还会增加分配内存的韶光，降落内存访问的效率。守旧式的标记清扫算法可能会将某些无用工具当做存活工具，导致内存透露。Golang的GC首先，Go 的 GC 目前利用的是无分代（工具没有代际之分）、不整理（回收过程中不对工具进行移动与整理）、并发（与用户代码并发实行）的三色标记清扫算法。可见，go在追踪式的GC模式中，引入了并发和三色标记清扫算法（V1.5），在go的不断调优下，已经是做到了准实时（1ms以内）的gc过程。
STW我们知道，在追踪式的GC过程中，我们须要进行两步操作，分别是标记和打消，为了避免程序本身运行给GC标记和打消带来不一致性，导致误删,为了担保同等性，golang会停滞除了GC模块程序之外的程序运行，这个过程被称为STW。
在这个过程中全体用户代码被停滞或者放缓实行， STW 越长，对用户代码造成的影响（例如延迟）就越大，早期 Go 对垃圾回收器的实现中 STW 的停顿韶光乃至是达到s级，对韶光敏感的实时通信等运用程序会造成巨大的影响。举例：
package mainimport ( "runtime" "time")func main() { go func() { for { } }() time.Sleep(time.Millisecond) runtime.GC() println("OK")}
在这行代码中，程序步骤大概如下：
主程序go func开启一个goroutine，并在goroutine中开启一个for去世循环。主程序Sleep(time.Millisecond),次数子协程已经开始实行。主协程主动调用GC的触发方法runtime.GC()。打印ok，退出程序结果：不会有打印结果（v1.14以前）。 v1.14之后可以打印。
缘故原由就在于GC中，会试图去等待其他goroutine所有的用户代码停滞，但显然，示例中的代码由于for {}无法停滞，导致始终无法进入 STW 阶段，造成程序卡去世。
可见，如果实际业务中在，当某个goroutine的代码一贯得不到停滞，就会导致程序一贯勾留在STW阶段而无法实行GC，造成程序卡去世或其他问题。
STW优化的版本迭代既然gc stw的持续韶光，直接影响到程序中由于gc所带来的负面影响，那我们须要想办法去缩短stw所持续的韶光，以是，go在各个版本中，便对gc的过程做了一定的优化。
go V1.1
程序运行开始。触发GC。GC 在须要进入 STW 时，须要关照并让所有的用户态代码停滞（stop the world）。mark(标记)。sweep(清理)。start the world。在这个过程中，gc过程是串行的，stw的韶光 = mark韶光+ sweep韶光
go V1.3版本的优化便是Mark和Sweep分离. Mark STW, Sweep并发。 也便是大致变成了一下流程：
程序运行开始。触发GC。GC 在须要进入 STW 时，须要关照并让所有的用户态代码停滞（stop the world）。mark。start the world。sweep(并发)。可以看到，这个时候的stw只存在于mark阶段，且sweep清扫阶段变成了并发实行。go V1.5 再次将mark也变成了并发的。
go1.8 整合插入樊篱和删除樊篱为稠浊写樊篱，将STW的停顿韶光真正进入到毫秒级。
go 1.14：替引入了异步抢占，办理了由于密集循环导致的 STW 韶光过长的问题。也便是上文示例所示的由于GC等待用户代码停滞韶光过长的问题。
mark(标记)是如何实现的？从上文可知，mark所作的事情，是识别出内存中的垃圾，我们也知道，当一个被声明的工具，我们可以确定已经没有程序须要利用到它的时候，他就可以被剖断为垃圾。 而go是基于追踪式方法又引入了三色标记法，实现了垃圾的识别问题。
三色标记法从垃圾回收器的视角来看，三色标记法是一种抽象，它规定了三种不同类型的工具，并用不同的颜色相称：
白色工具（可能去世亡）：未被回收器访问到的工具。在回收开始阶段，所有工具均为白色，当回收结束后，白色工具均不可达。灰色工具（波面）：已被回收器访问到的工具，但回收器须要对个中的一个或多个指针进行扫描，由于他们可能还指向白色工具。玄色工具（确定存活）：已被回收器访问到的工具，个中所有字段都已被扫描，玄色工具中任何一个指针都不可能直接指向白色工具。回收器回收器（Collector）：卖力实行垃圾回收的代码。对应的还有赋值器。
赋值器赋值器（Mutator）：这一名称实质上是在指代用户态的代码。由于对垃圾回收器而言，用户态的代码仅仅只是在修正工具之间的引用关系，也便是在工具图（工具之间引用关系的一个有向图）上进行操作。
追踪式GC方法提到一个很主要的内容，那便是根工具。那什么是根工具呢？根工具在垃圾回收的术语中又叫做根凑集，它是垃圾回收器在标记过程时最先检讨的工具，包括：
全局变量：程序在编译期就能确定的那些存在于程序全体生命周期的变量。实行栈：每个 goroutine 都包含自己的实行栈，这些实行栈上包含栈上的变量及指向分配的堆内存区块的指针。寄存器：寄存器的值可能表示一个指针，参与打算的这些指针可能指向某些赋值器分配的堆内存区块。也便是说，三色标记法是从根工具出发，不断地把白色工具（可能去世亡）一步步标记为灰色（确认存活，还须要扫描）、玄色工具（存活）的过程。
可以大略理解为（不是真正的go gc的逻辑）：
GC开始，所有工具都是白色节点stw开始 用户程序停滞mark，三色标记法标记可达工具。查找所有灰节点的子节点（最开始的时候根节点是灰色）。把灰色节点下可以找到有关联的白色子节点标记为灰色。灰色节点下所有子节点遍历完之后，把灰色节点本身标记为玄色（不是垃圾）。再从灰节点列表中拿出一个灰节点，重复子节点查找，标记操作。所有节点遍历完 mark结束。stw 结束 用户程序开始。sweep 清理剩下的所有白色节点（垃圾）。动图示例（图中的颜色不是黑灰白，而是利用蓝黄白相对应）:
可以看到，以上的mark过程即2-9的过程，同样处于一个stw的过程中，也便是说，Golang GC真正运行的时候，用户程序是不能够运行的。
为什么须要这样呢，由于GC mark的时候，如果不关闭用户程序的操作，那我们就可能涌现以下情形导致缺点标记和打消：
个中C是根节点，在gc开始的准备阶段被标记为灰色
时序
回收器
赋值器
1
A是C的子节点，A着色为灰色
2
C的所有子节点遍历完毕，C被着色为玄色
3
C.ref3 = C.ref2.ref1 C关联B
4
A断开于B的关联
5
遍历灰色节点A的所有子节点，由于此时 A.ref1 为 nil ，以是没有子节点
6
A被着色为玄色
7
回收器：由于所有子节点均已标记，回收器也不会重新扫描已经被标记为玄色的工具，此时 A 被着色为玄色， scan(A) 什么也不会发生，进而 B 在这次回收过程中永久不会被标记为玄色，进而缺点地被回收。
结果：虽然根节点有指向B的关系，但是B被缺点的回收了。
为什么会涌现这个情形？很明显，根本缘故原由是当回收器在实行标记的时候，赋值器也在不断的变动工具之间的关系。以是在mark标记过程中，我们依旧要STW这个过程。
有办法办理这个问题吗？也便是我在mark标记的过程中，赋值器同样可以实行，也便是用户程序可以运行。
写樊篱写樊篱是一个在并发垃圾回收器中才会涌现的观点，垃圾回收器的精确性表示在：不应涌现工具的丢失，也不应缺点的回收还不须要回收的工具。 大佬们已经证明，当以下两个条件同时知足时会毁坏垃圾回收器的精确性：
条件 1: 赋值器修正工具图，导致某一玄色工具引用白色工具；条件 2: 从灰色工具出发，到达白色工具的、未经访问过的路径被赋值器毁坏。只要能够避免个中任何一个条件，则不会涌现工具丢失的情形，由于：
如果条件 1 被避免，则所有白色工具均被灰色工具引用，没有白色工具会被遗漏；如果条件 2 被避免，即便白色工具的指针被写入到玄色工具中，但从灰色工具出发，总存在一条没有访问过的路径，从而找达到到白色工具的路径，白色工具终极不会被遗漏。也便是说，在上面举例中，C玄色节点不能直接指向一个白色节点"B"，或者灰色节点A不能删除白色节点"B"的引用，就不会导致缺点回收的问题。
很显然，在go想要把mark过程从stw等分离出来，与业务程序并行，就要办理全体问题，写樊篱是go团队最开始的方法。
写樊篱是针对赋值器改变工具间引用关系改变时的一种同步机制，有两种非常经典的写樊篱：Dijkstra 插入樊篱和 Yuasa 删除樊篱。
Dijkstra 插入樊篱插入樊篱旨在毁坏精确性的条件一，也便是玄色工具建立于白色工具的链接。
// 灰色赋值器 Dijkstra 插入樊篱func DijkstraWritePointer(slot unsafe.Pointer, ptr unsafe.Pointer) {` shade(ptr) slot = ptr}
由于玄色工具不会再被扫描标记，那如果一旦有未扫描的工具被关联到一个玄色工具上，且全体白色工具没有其他关联，就会导致白色工具被标记打消。
以是Dijkstra 插入樊篱在建立关系之前，把指针本身着色成灰色，放入待扫描的灰色节点池中，我们知道，mark会扫描标记所有灰色池，所有灰色终极都会变成玄色而不会被打消。
显然，这可以办理并发mark和用户程序赋值器的不一致性问题，但是它的缺陷便是可能会导致该当被删除的工具，在mark过程中由于存在赋值操作，而在本次gc过程中未被回收。
网图解释：
可以瞥见，在C于B建立关系ref3的时候，A并未扫描到B，但是B已经变成灰色，进而终极被标记成玄色。
Yuasa 删除樊篱插入樊篱针对的是条件1，那么删除樊篱便是针对的条件2：从灰色工具出发，到达白色工具的、未经访问过的路径被赋值器毁坏。。
1. `// 玄色赋值器 Yuasa 樊篱` 2. `func YuasaWritePointer(slot unsafe.Pointer, ptr unsafe.Pointer) {` 3. ` shade(slot)` 4. ` slot = ptr` 5. `}`
通过代码可以看到，当赋值器须要删除节点的关联时，会将父节点的颜色shade(slot)着色成灰色，也便是须要重新扫描。
网图解释：
很明显，删除樊篱的缺陷便是会带来重复扫描的问题，由于一旦存在删除关系的操作，就须要重新扫描。
但是有缺点没紧要，相对精良就可以。在三色标记法+写樊篱的担保下，我们就可以让mark的大部分过程从stw中解放出来，并且可以对mark进行并发操作。
这时候，我们理解的gc流程就可以优化成：
GC开始，所有工具都是白色节点stw开始 用户程序停滞gc准备事情(根节点标记为灰色，写樊篱开启...）stw结束，mark开始（并发，于用户程序并行）。查找所有灰节点的子节点（最开始的时候根节点是灰色）。把灰色节点下可以找到有关联的白色子节点标记为灰色。灰色节点下所有子节点遍历完之后，把灰色节点本身标记为玄色（不是垃圾）。再从灰节点列表中拿出一个灰节点，重复子节点查找，标记操作。所有节点遍历完 mark结束。sweep 清理剩下的所有白色节点（垃圾）。也便是说，stw的过程仅包含了2-4这几个步骤，那stw的韶光相对的减少很多，并且mark、sweep的并发操作，可以让全体流程都缩短很多。
写樊篱优化很显然，golang的开拓者们知道自己选择的写樊篱的优缺陷，以是也在版本的更迭中不断的去优化，使其能做到更好。
如上版本迭代所示，golang团队的职员在V1.5进入mark的并发版本（普通写樊篱）之后，V1.8就优化了写樊篱变成稠浊写樊篱，于其他的GC优化一起，把Golang GC真正的带入了毫秒级时期。
Golang GC的流程当然，这只是我们所梳理出来的GC过程，真正的Golang GC流程该当是有出入的，比如mark结束之后该当会有写樊篱关闭的阶段，而这个阶段该当也会有一个stw。
当前版本的 Go 以 STW 为界线，可以将 GC 划分为五个阶段（来自：https://www.bookstack.cn/read/qcrao-Go-Questions/GC-GC.md ）
阶段
解释
赋值器状态
SweepTermination
清扫终止阶段，为下一个阶段的并发标记做准备事情，启动写樊篱
STW
Mark
扫描标记阶段，与赋值器并发实行，写樊篱开启
并发
MarkTermination
标记终止阶段，担保一个周期内标记任务完成，停滞写樊篱
STW
GCoff
内存清扫阶段，将须要回收的内存归还到堆中，写樊篱关闭
并发
第一个阶段 gc开始 （stw）
stop the world 停息程序实行启动标记事情携程（ mark worker goroutine ），用于第二阶段启动写樊篱将root 跟工具放入标记行列步队（放入标记行列步队里的便是灰色）start the world 取消程序停息，进入第二阶段第二阶段 marking（这个阶段，用户程序跟标记携程是并行的）
从标记行列步队里取出工具，标记为玄色然后检测是否指向了另一个工具，如果有，将另一个工具放入标记行列步队在扫描过程中，用户程序如果新创建了工具 或者修正了工具，就会触发写樊篱，将工具放入单独的 marking行列步队，也便是标记为灰色扫描完标记行列步队里的工具，就会进入第三阶段第三阶段 处理marking过程中修正的指针 （stw）
stop the world 停息程序将marking阶段 修正的工具 触发写樊篱产生的行列步队里的工具取出，标记为玄色然后检测是否指向了另一个工具，如果有，将另一个工具放入标记行列步队扫描完marking行列步队里的工具，start the world 取消停息程序 进入第四阶段第四阶段 sweep 打消白色的工具 到这一阶段，所有内存要么是玄色的要么是白色的，清楚所有白色的即可
有没有GC的利害首先，我们可以先理解一下GC在那些措辞里面有涉及。
有GC模块的措辞：
GolangPythonPHPJava...没有GC的措辞：
CC++看到这样的凑集分类，大致就明白，没有GC的上风：
程序运行该当会快一些，没有GC的额外开销。精准的手动内存管理，极致的利用机器的性能劣势该当便是须要手动管理内存，开拓周期和开拓所须要的技能知识储备会哀求高一些。
相对的，有GC的上风便是 开拓职员可以专心完成业务代码，而不用在内存管理这块花太多心思。同样的，GC所带来的开销肯定会让程序相对没那么快。各有利害，根据实际情形选择就好。
JAVA的GC我倒是没怎么利用过Java，由于学习GC大略理解了一下。
java的GC也是基于追踪式办法的，它本身实现的Java GC完成了分代GC的详细实现。
分代GC大略说，分代GC的目的是减少须要频繁扫描的节点数量，希望每一次标注的扫描都是故意义的。
他的背景是：大多数的工具是不会持久生动的，而真正持久生动的工具不用每一次都去参与正常的GC。
他的实现：以是利用新生代、老年代进行工具进行区分，然后根据不同的频率对不同类型的工具进行扫描回收。
年轻代险些所有新天生的工具首先都是放在年轻代的。当一个变量在新生代经历一次GC之后，他的年事+1。
年迈代在年轻代中经历了N次垃圾回收后仍旧存活的工具，就会被放到年迈代中。因此，可以认为年迈代中存放的都是一些生命周期较长的工具。
分代GC回收
很明显，当工具经由分代后，我们可以用不同的GC，以不同的频率去清理对应代的工具。新生代的就须要频繁一些，而老年代的就可以间隔长一些，不用每次都去扫描，这样可以减少GC过程中须要扫描的工具的额数量。
当然，不管是Java还是Golang的GC，都是须要经由STW这个过程的， 不过经由不断的迭代更新，都已经已达到了用户代码险些无法感知到的状态。
GOlang 和 Java对GC的调优Java可以通过各种参数调优，以是Java的GC彷佛是必须要熟习的。
GolangGo 的 GC 被设计为极致简洁，与较为成熟的 Java GC 的数十个可控参数比较，严格意义上来讲，Go 可供用户调度的参数只有 GOGC 环境变量，他大略来说便是一个阈值，数值越大，GC实行的频率越低。
当然GC调优的核心还是:
减小GC对资源的花费，提高业务程序本身对 CPU 的利用率。减少并复用内存。须要时，降落 GC 的运行频率。GO 须要引入分代GC吗？看网上的有人说，go的GC优化或许就会基于当前的GC引入分代GC的内容，由于当前GC虽然效率上去了，但是却是用CPU的开销来撑起来的，以是还有优化的空间。
也有一些人说，分代假设并不适用于 Go 的运行栈机制，年轻代工具在栈上就已经去世亡，扫描本就该回收的实行栈并没有为由于分代假设带来明显的性能提升。这也是这一设计终极没有被采取的紧张缘故原由。
