每个版本的Golang的垃圾回收都在不断优化中，而且方法和策略都在变化，因此这里只是总结出以下几个关键点：
- 什么样的数据需要GC
- 触发GC的条件是什么
- GC时发生了什么
- 能否从代码层面上提高GC的效率
Golang在确定的时间，或者内存分配到达一定程度时，进行GC。GC时，会停止STW（Stop The World），即对外的服务都会暂停，然后进行垃圾回收处理。Go1.12引入了三色标记法和write-barrier的方式；在Go1.14中，引入看了抢占式回收机制。
write-barrier机制：
假设有4个G在运行，如下图：
进行GC的时候，需要STW，此时的4个G都要停止工作。如果有一个没有停止工作的，则GC暂时不能发生。比如下图：
第4个G没停止工作，则GC需要等待其结束。Go1.14中，可以抢占第4个G的工作状态，保存其状态后，再进行GC
GC的时候，GC机制会征用一些G并发辅助进行工作，一般有25%的G会被征用。
整体工作流程：
- 创建白、灰和黑三个集合
- 初始化所有的待回收对象都是白色的
- 从根节点遍历对象，不递归；遍历到的白色对象放到灰色集合当中
- 之后遍历灰色集合，把灰色对象引用的对象，从白色集合中放入灰色集合，并把现在的灰色对象放入黑色集合中
- 重复上一步，知道灰色集合是空的
- 通过write-barrier检测对象的变化，重复以上操作
- 回收所有的白色对象
永远不要过早的优化程序！！！
栈内存分配和回收的代价远远小于堆内存。Golang的垃圾回收发生在全局的堆上和每个Goroutinue的栈上。回收栈内存只需要两个CPU指令，push和pop。然而，分配在栈内存的数据，需要在编译期间就得知道type和size。
go build -gcflags '-m'发生内存逃逸的几种情况：
chan[]*stringinterface总结一下发生逃逸的结论：
- 首先明确一点，Golang中所有的数据都是按值传递，这点和C语言是一样的（注意Golang中的数组名是值，和C的差别）。所谓的map、slice和chan等是引用，其本质原因是，这些结构的内部都有指针，复制的时候，内部都是复制的指针，因此表现的是传值。
- 在函数调用中，对于指针的情况，只要指向的地址的所有者只有一个，那么必然是栈回收；而一旦存在地址存在不确定变化时，则转换成堆的数据。比如slice情况，因为slice会扩容或者缩容，因此造成不确定情况。
以下使用代码示例说明：
package main
func main() {
ch := make(chan int, 1)
x := 5
ch <- x // x不发生逃逸，因为只是复制的值
ch1 := make(chan *int, 1)
y := 5
py := &y
ch1 <- py // y逃逸，因为地址传入了chan
z := 5
pz := &z // z不逃逸，因为是确定性析构
*pz += 1
}
go build -gcflags ./main.go# command-line-arguments
.\main.go:3:6: can inline main as: func() { ch := make(chan int, 1); x := 5; ch <- x; ch1 := make(chan *int, 1); y := 5; py := &y; ch1 <- py; z := 5; pz := &z; *pz += 1 }
.\main.go:9:2: y escapes to heap:
.\main.go:9:2: flow: py = &y:
.\main.go:9:2: from &y (address-of) at .\main.go:10:8
.\main.go:9:2: from py := &y (assign) at .\main.go:10:5
.\main.go:9:2: flow: {heap} = py:
.\main.go:9:2: from ch1 <- py (send) at .\main.go:11:6
.\main.go:9:2: moved to heap: y
如果使用slice和map的模式：
package main
func main() {
var x int
x = 10
var ls []*int
ls = append(ls, &x)
var y int
var mp map[string]*int
mp["y"] = &y
}
结论分析：
# command-line-arguments
.\main.go:3:6: can inline main as: func() { var x int; x = <N>; x = 10; var ls []*int; ls = <N>; ls = append(ls, &x); var y int; y = <N>; var mp map[string]*int; mp = <N>; mp["y"] = &y }
.\main.go:4:6: x escapes to heap:
.\main.go:4:6: flow: {heap} = &x:
.\main.go:4:6: from &x (address-of) at .\main.go:7:18
.\main.go:4:6: from append(ls, &x) (call parameter) at .\main.go:7:13
.\main.go:9:6: y escapes to heap:
.\main.go:9:6: flow: {heap} = &y:
.\main.go:9:6: from &y (address-of) at .\main.go:11:12
.\main.go:9:6: from mp["y"] = &y (assign) at .\main.go:11:10
.\main.go:4:6: moved to heap: x
.\main.go:9:6: moved to heap: y
使用闭包捕获指针的模式：
package main
import "time"
func main() {
x := 10
go func(x *int) {
*x += 1
}(&x) // 捕获的瞬间，x没有移动到heap上，但是整个闭包移动到了heap上，因此x也跟随闭包被移动到heap上了
time.Sleep(time.Second * 2)
}
结论分析：
# command-line-arguments
.\main.go:5:6: cannot inline main: unhandled op GO
.\main.go:7:5: can inline main.func1 as: func(*int) { *x += 1 }
.\main.go:7:5: func literal escapes to heap:
.\main.go:7:5: flow: {heap} = &{storage for func literal}:
.\main.go:7:5: from func literal (spill) at .\main.go:7:5
.\main.go:7:5: from go (func literal)(&x) (call parameter) at .\main.go:7:2
.\main.go:6:2: x escapes to heap:
.\main.go:6:2: flow: {heap} = &x:
.\main.go:6:2: from &x (address-of) at .\main.go:9:4
.\main.go:6:2: from go (func literal)(&x) (call parameter) at .\main.go:7:2
.\main.go:7:10: x does not escape
.\main.go:6:2: moved to heap: x
.\main.go:7:5: func literal escapes to heap
对于slice扩容的情况：
package main
import (
"os"
"strconv"
)
func main() {
ls := []int{1, 2, 3}
ls = append(ls, 4) // 确定性的，不逃逸，编译期间可以知道
var n int
n, _ = strconv.Atoi(os.Args[1]) // 输入数据后，则结果不可知，因此可能逃逸
ls1 := []int{1, 2, 3}
for i := 0; i < n; i++ {
ls1 = append(ls1, 1)
}
}
interface类型的GC，涉及使用interface类型转换并调用对应的方法的时候，都会发生内存逃逸，给出代码示例：
package main
type foo interface {
fooFunc()
}
type foo1 struct{}
func (f1 foo1) fooFunc() {}
type foo2 struct{}
func (f2 *foo2) fooFunc() {}
func main() {
var f foo
f = foo1{}
f.fooFunc() // 调用方法时，发生逃逸，因为方法是动态分配的
f = &foo2{}
f.fooFunc()
}
执行说明：
go-code ➤ go build -gcflags "-m" main.go
# command-line-arguments
.\main.go:9:6: can inline foo1.fooFunc
.\main.go:13:6: can inline (*foo2).fooFunc
.\main.go:13:7: f2 does not escape
.\main.go:17:4: foo1 literal escapes to heap
.\main.go:19:6: &foo2 literal escapes to heap
<autogenerated>:1: leaking param: .this
<autogenerated>:1: inlining call to foo1.fooFunc
<autogenerated>:1: .this does not escape
返回slice等的情况：
package main
func foo() []int {
return []int{1, 2, 3}
}
func main() {
ls := foo() // 发生逃逸
ls = append(ls, 1)
}
分析结果：
# command-line-arguments
.\main.go:3:6: can inline foo as: func() []int { return []int literal }
.\main.go:7:6: can inline main as: func() { ls := foo(); ls = append(ls, 1) }
.\main.go:8:11: inlining call to foo func() []int { return []int literal }
.\main.go:4:14: []int literal escapes to heap:
.\main.go:4:14: flow: ~r0 = &{storage for []int literal}:
.\main.go:4:14: from []int literal (spill) at .\main.go:4:14
.\main.go:4:14: from return []int literal (return) at .\main.go:4:2
.\main.go:4:14: []int literal escapes to heap
.\main.go:8:11: []int literal does not escape
传值还是传指针的问题：
根据上面的分析，指针更容易出现内存逃逸的现象。而一旦发生了内存逃逸，则不可避免地对GC造成潜在的压力。有种错误的观念：传指针的代价总是比传值的拷贝代价小。这种观念只在像C语言这种没有GC的低级语言中可能适用。原因如下：
- 对指针解引用的时候，编译器会进行一些检查。
- 指针一般都不是临近地址的引用，而复制时，一般都是CPU cash中的数据，cash line内的数据的复制，速度基本和一个复制指针相等
nterfaceinterface几个总结
interface- https://juejin.im/post/5d2825bff265da1b6836e8d4
- https://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/
- https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/
- https://i6448038.github.io/2019/03/04/golang-garbage-collector/
- http://idiotsky.top/2017/08/16/gc-three-color/