从Gov1.12版本开始，Go使用了非分代的、并发的、基于三色标记清除的垃圾回收器。
关于垃圾回收，比较常见的算法有引用计数、标记清除和分代收集，Golang语言使用的垃圾回收算法是标记清除。
Golang语言的标记清除垃圾回收算法，为了防止GC扫描时内存变化引起的混乱。那么就需要 STW，即Stop The World。具体在Golang语言中是指，在GC时先停止所有goroutine。再进行垃圾回收，等待垃圾回收结束后再恢复所有被停止的goroutine。
标记清除方法
启动STW，暂停程序的业务逻辑，找出不可达对象和可达对象。
将所有可达对象做标记，清除未标记的对象。停止STW，程序继续执行。循环往复，直到进程程序生命周期结束。因为STW需要暂停程序，为了减少暂停程序的时间。将清除操作移出 STW执行周期，但是优化效果不明显。所谓三色标记，实际上只是为了方便叙述而抽象出来的一种说法，三色对应垃圾回收过程中对象的三种状态。白色是对象未被标记，gcmarkBits对应位为0，该对象将会在本次GC中被清理。灰色是对象还在标记队列中等待被标记，黑色是对象已被标记，gcmarkBits对应位为0，该对象将会在本次 GC中被回收。
Golang采用了三色标记法来进行垃圾回收，那么在什么场景下会触发这个回收动作呢？
源码主要位于文件 src/runtime/mgc.go go version 1.16
触发条件从大方面说，可分为 手动触发 和 系统触发 两种方式。手动触发一般很少用，主要由开发者通过调用 runtime.GC() 函数来实现，而对于系统自动触发是 运行时 根据一些条件判断来进行的，这也正是本文要介绍的内容。
不管哪种触发方式，底层回收机制是一样的，所以我们先看一下手动触发，根据它来找系统触发的条件。
可以看到开始执行GC的是 gcStart() 函数，它有一个 gcTrigger 参数，是一个触发条件结构体，它的结构体也很简单。
其实在Golang 内部所有的GC都是通过 gcStart() 函数，然后指定一个 gcTrigger 的参数来开始的，而手动触发指定的条件值为 gcTriggerCycle 。 gcStart 是一个很复杂的函数，有兴趣的可以看一下源码实现。
对于 kind 的值有三种，分别为 gcTriggerHeap 、 gcTriggerTime 和 gcTriggerCycle 。
运行时会通过 gcTrigger.test() 函数来决定是否需要触发GC，只要满足上面基中一个即可。
到此我们基本明白了这三种触发GC的条件，那么对于系统自动触发这种，Golang 从一个程序的开始到运行，它又是如何一步一步监控到这个条件的呢？
其实 runtime 在程序启动时，会在一个初始化函数 init() 里启用一个 forcegchelper() 函数，这个函数位于 proc.go 文件。
为了减少系统资源占用，在 forcegchelper 函数里会通过 goparkunlock() 函数主动让自己陷入休眠，以后由 sysmon() 监控线程根据条件来恢复这个gc goroutine。
可以看到 sysmon() 会在一个 for 语句里一直判断这个 gcTriggerTime 这个条件是否满足，如果满足的话，会将 forcegc.g 这个 goroutine 添加到全局队列里进行调度(这里 forcegc 是一个全局变量)。
调度器在调度循环 runtime.schedule 中还可以通过垃圾收集控制器的 runtime.gcControllerState.findRunnabledGCWorker 获取并执行用于后台标记的任务。
Golang的内存分配是由golang runtime完成，其内存分配方案借鉴自tcmalloc。
主要特点就是
本文中的element指一定大小的内存块是内存分配的概念，并为出现在golang runtime源码中
本文讲述x8664架构下的内存分配
Golang 内存分配有下面几个主要结构
Tiny对象是指内存尺寸小于16B的对象，这类对象的分配使用mcache的tiny区域进行分配。当tiny区域空间耗尽时刻，它会从mcache.alloc[tinySpanClass]指向的mspan中找到空闲的区域。当然如果mcache中span空间也耗尽，它会触发从mcentral补充mspan到mcache的流程。
小对象是指对象尺寸在（16B，32KB]之间的对象，这类对象的分配原则是：
1、首先根据对象尺寸将对象归为某个SpanClass上，这个SpanClass上所有的element都是一个统一的尺寸。
2、从mcache.alloc[SpanClass]找到mspan，看看有无空闲的element，如果有分配成功。如果没有继续。
3、从mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合适的mspan，返回给mcache。如果没有找到就进入mcentral.grow()—>mheap.alloc()分配新的mspan给mcentral。
大对象指尺寸超出32KB的对象，此时直接从mheap中分配，不会走mcache和mcentral，直接走mheap.alloc()分配一个SpanClass==0 的mspan表示这部分分配空间。
对于程序分配常用的tiny和小对象的分配，可以通过无锁的mcache提升分配性能。mcache不足时刻会拿mcentral的锁，然后从mcentral中充mspan 给mcache。大对象直接从mheap 中分配。
在x8664环境上，golang管理的有效的程序虚拟地址空间实质上只有48位。在mheap中有一个pages pageAlloc成员用于管理golang堆内存的地址空间。golang从os中申请地址空间给自己管理，地址空间申请下来以后，golang会将地址空间根据实际使用情况标记为free或者alloc。如果地址空间被分配给mspan或大对象后，那么被标记为alloc，反之就是free。
Golang认为地址空间有以下4种状态：
Golang同时定义了下面几个地址空间操作函数：
在mheap结构中，有一个名为pages成员，它用于golang 堆使用虚拟地址空间进行管理。其类型为pageAlloc
pageAlloc 结构表示的golang 堆的所有地址空间。其中最重要的成员有两个：
在golang的gc流程中会将未使用的对象标记为未使用，但是这些对象所使用的地址空间并未交还给os。地址空间的申请和释放都是以golang的page为单位（实际以chunk为单位）进行的。sweep的最终结果只是将某个地址空间标记可被分配，并未真正释放地址空间给os，真正释放是后文的scavenge过程。
在gc mark结束以后会使用sweep()去尝试free一个span；在mheap.alloc 申请mspan时刻，也使用sweep去清扫一下。
清扫mspan主要涉及到下面函数
如上节所述，sweep只是将page标记为可分配，但是并未把地址空间释放；真正的地址空间释放是scavenge过程。
真正的scavenge是由pageAlloc.scavenge()—>sysUnused()将扫描到待释放的chunk所表示的地址空间释放掉（使用sysUnused()将地址空间还给os）
golang的scavenge过程有两种：
