源码主要位于文件 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 获取并执行用于后台标记的任务。
Go1.5开发环境依赖Go1.4版本作为引导，因为Go1.5使用Go本身来编译安装Go，所以必须保证服务器上已经安装Go1.4，这完全是为了解决先有鸡还是先有蛋的问题，当然如果你想避免编译安装1.4也可以直接使用二进制包。在这里假设你希望将go1.5安装到$HOME/go1.5目录下，只需要以下几步：
下载Go1.5的源码放到$HOME/go1.5目录下
在安装Go1.5之前需要将Go1.4放到$HOME/go1.4下面或者export GOROOT_BOOTSTRAP=/go1.4安装目录/
到$HOME/go1.5/src/下执行all.bash即可
我习惯将软件安装至/usr/local/下，以下为我安装Go1.5(/usr/local/go1.5)的步骤：
wget https://storage.googleapis.com/golang/go1.5.1.src.tar.gz
tar zxvf go1.5.1.src.tar.gz
mv ./go /usr/local/go1.5
wget https://storage.googleapis.com/golang/go1.4.3.src.tar.gz
tar zxvf go1.4.3.src.tar.gz
mv ./go /usr/local/go-bootstrap1.4/
cd /usr/local/go-bootstrap1.4/src
./all.bash //编译安装Go1.4，有可能test不通过，只要编译通过，test可忽略，目的是需要go1.4的二进制包来编译1.5
cd /usr/local/go1.5/src
GOROOT_BOOTSTRAP=/usr/local/go-bootstrap1.4 ./all.bash
//可在环境变量中添加GOROOT_BOOTSTRAP，然后再编译Go1.5
以下为网摘：
From C to Go
The gc tool chain is being converted from C to Go.
An ongoing process, started early 2014.
Russ Cox says "It'll be done by March [2015]."
New link tool to replace 6l, 8l, etc.
New asm tool to replace 6a, 8a, etc.
Machine-translated gc to replace 6g, 8g, etc.
Design doc:
golang.org/s/go13compiler
Go 1.5 will have no C code in the tool chain or runtime.
Go语言将使用Go代替C重写运行时环境
Go 1.4 的合并窗口在 9 月份将关闭，从现在开始到12月份发布 Go 1.4 之前将只接受 bug 修复和小调整。
Go 1.4 最主要的变化是将使用 Go 语言本身来重写 Go 的运行时，而之前是采用 C 语言开发。这也是为什么 Go 的发行版中包含一个 C
编译器的原因。
使用 Go 重写的好处是：
当前如果在 Goroutine 的调用堆栈中发现 C 代码，runtime 将在需要增长堆栈时回滚到老的堆栈方法。如果使用 Go 来重写
runtime，那么堆栈拷贝的方法就会更加高效
目前转换工作只计划转 Go 编译器 (5g, 6g, 8g), 而不是 C 编译器，降低运行时中的 C 代码行数，甚至可能完全清除
注意
这是 golang.org 分发版，也就是 gc ，而不是 gccgo
这是不同的 C 编译器，gc 工具链将使用你系统的 C 编译器来编译，gc 运行时则使用它的 C 编译器来编译
8月20日后增加的转换行可能跟 this request 有关.
Go语言将使用Go代替C重写运行时环境
— 从现在开始到12月份 Go 1.4版本发布前，Go将只接受Bug修复和小范围的调整，Go
1.4版本将实现使用Go语言来重写Go的运行时环境。
