什么是内存逃逸分析
内存逃逸分析是go的编译器在编译期间，根据变量的类型和作用域，确定变量是堆上还是栈上
简单说就是编译器在编译期间，对代码进行分析，确定变量分配内存的位置。如果变量需要分配在堆上，则称作内存逃逸了。
为什么需要逃逸分析
因为go语言是自动自动内存管理的，也就是有GC的。开发者在写代码的时候不需要关心考虑内存释放的问题，这样编译器和go运行时（runtime）就需要准确分配和管理内存，所以编译器在编译期间要确定变量是放在堆空间和栈空间。
如果变量放错了位置会怎样
我们知道，栈空间和生命周期是和函数生命周期相关的，如果一个函数的局部变量离开了函数的范围，比如函数结束时，局部变量就会失效。所以要把这样的变量放到堆空间上。
既然如此，那把所有在变量都放在堆上不就行了，这样一来，是没啥问题了，但是堆内存的使用成本比占内存要高好多。使用堆内存，要向操作系统申请和归还，而占内存是程序运行时就确定好了，如何使用完全由程序自己确定。在栈上分配和回收内存成本很低，只需要 2 个 CPU 指令：PUSH 和 POP，push 将数据放到到栈空间完成分配，pop 则是释放空间。
比如 C++ 经典错误，return 一个 函数内部变量的指针
1#include<iostream>
2
3int* one(){
4 int i = 10;
5 return &i;
6}
7
8int main(){
9 std::cout << *one();
10}
这段代码在编译的时候会如下警告:
1one.cpp: 在函数‘int* one()’中:
2one.cpp:4:6: 警告：返回了局部变量的‘i’的地址 [-Wreturn-local-addr]
3 int i = 10;
4 ^
虽然程序的运行结果大多数时候都和我们预期的一样，但是这样的代码还是有风险的。
这样的代码在go里就完全没有问题了，因为go的编译器会根据变量的作用范围确定变量是放在栈上和堆上。
内存逃逸场景
go的编译器提供了逃逸分析的工具，只需要在编译的时候加上 -gcflags=-m 就可以看到逃逸分析的结果了
常见的有4种场景下会出现内存逃逸
return 局部变量的指针
1package main
2
3func main() {
4
5}
6
7func One() *int {
8 i := 10
9 return &i
10}
执行 go build -gcflags=-m main.go
1# command-line-arguments
2.\main.go:3:6: can inline main
3.\main.go:7:6: can inline One
4.\main.go:8:2: moved to heap: i
可以看到变量 i 已经被分配到堆上了
interface{} 动态类型
当函数传递的变量类型是 interface{} 类型的时候，因为编译器无法推断运行时变量的实际类型，所以也会发生逃逸
1package main
2
3import "fmt"
4
5func main() {
6 i := 10
7 fmt.Println(i)
8}
执行 go build -gcflags=-m .\main.go
1.\main.go:11:13: inlining call to fmt.Println
2.\main.go:11:13: i escapes to heap
3.\main.go:11:13: []interface {} literal does not escape
4<autogenerated>:1: .this does not escape
5<autogenerated>:1: .this does not escape
可看到，i 也被分配到堆上了
栈空间不足
因为栈的空间是有限的，所以在分配大块内存时，会考虑栈空间内否存下，如果栈空间存不下，会分配到堆上。
1package main
2
3func main() {
4 Make10()
5 Make100()
6 Make10000()
7 MakeN(5)
8}
9
10func Make10() {
11 arr10 := make([]int, 10)
12 _ = arr10
13}
14
15func Make100() {
16 arr100 := make([]int, 100)
17 _ = arr100
18}
19
20func Make10000() {
21 arr10000 := make([]int, 10000)
22 _ = arr10000
23}
24
25func MakeN(n int) {
26 arrN := make([]int, n)
27 _ = arrN
28}
执行 go build -gcflags=-m main.go
1# command-line-arguments
2.\main.go:10:6: can inline Make10
3.\main.go:15:6: can inline Make100
4.\main.go:20:6: can inline Make10000
5.\main.go:25:6: can inline MakeN
6.\main.go:3:6: can inline main
7.\main.go:4:8: inlining call to Make10
8.\main.go:5:9: inlining call to Make100
9.\main.go:6:11: inlining call to Make10000
10.\main.go:7:7: inlining call to MakeN
11.\main.go:4:8: make([]int, 10) does not escape
12.\main.go:5:9: make([]int, 100) does not escape
13.\main.go:6:11: make([]int, 10000) escapes to heap
14.\main.go:7:7: make([]int, n) escapes to heap
15.\main.go:11:15: make([]int, 10) does not escape
16.\main.go:16:16: make([]int, 100) does not escape
17.\main.go:21:18: make([]int, 10000) escapes to heap
18.\main.go:26:14: make([]int, n) escapes to heap
可以看到当需要分配长度为10，100的int类型的slice时，不需要逃逸到堆上，在栈上就可以，如果slice长度达到1000时，就需要分配到堆上了。
还有一种情况，当在编译期间长度不确定时，也需要分配到堆上。
闭包
1package main
2
3func main() {
4 One()
5}
6
7func One() func() {
8 n := 10
9 return func() {
10 n++
11 }
12}
在函数One中return了一个匿名函数，形成了一个闭包，看一下逃逸分析
1# command-line-arguments
2.\main.go:3:6: can inline main
3.\main.go:9:9: can inline One.func1
4.\main.go:8:2: moved to heap: n
5.\main.go:9:9: func literal escapes to heap
可以看到 变量 n 也分配到堆上了
还有一种情况，new 出来的变量不一定分配到堆上
1package main
2
3func main() {
4 i := new(int)
5 _ = i
6}
像java C++等语言，new 出来的变量正常都会分配到堆上，但是在go里，new出来的变量不一定分配到堆上，至于分配到哪里，还是看编译器的逃逸分析来确定
编译一下看看
go build -gcflags=-m main.go
1# command-line-arguments
2.\main.go:3:6: can inline main
3.\main.go:4:10: new(int) does not escape
可以看到 new出来的变量，并没有逃逸，还是在栈上。
常见的内存逃逸场景差不多就是这些了，再说一下内存逃逸带来的影响吧
性能
那肯定就是性能问题了，因为操作栈空间比堆空间要快多了，而且使用堆空间还会有GC问题，频繁的创建和释放堆空间，会增加GC的压力
一个简单的例子测试一下，一般来说，函数返回结构体的指针比直接返回结构体性能要好
1package main
2
3import "testing"
4
5type MyStruct struct {
6 A int
7}
8
9func BenchmarkOne(b *testing.B) {
10 for i := 0; i < b.N; i++ {
11 One()
12 }
13}
14
15//go:noinline
16func One() MyStruct {
17 return MyStruct{
18 A: 10,
19 }
20}
21
22func BenchmarkTwo(b *testing.B) {
23 for i := 0; i < b.N; i++ {
24 Two()
25 }
26}
27
28//go:noinline
29func Two() *MyStruct {
30 return &MyStruct{
31 A: 10,
32 }
33}
注意 被调用的函数一定要加上 //go:noinline 来禁止编译器内联优化
然后执行
go test -bench . -benchmem
1goos: windows
2goarch: amd64
3pkg: escape
4BenchmarkOne-6 951519297 1.26 ns/op 0 B/op 0 allocs/op
5BenchmarkTwo-6 74933496 15.4 ns/op 8 B/op 1 allocs/op
6PASS
7ok escape 2.698s
可以明显看到 函数 One返回结构体 比 函数Two 返回 结构体指针 的性能更好，而且还不会有内存分配，不会增加GC压力
抛开结构体的大小谈性能都是耍流氓，如果结构体比较复杂了还是指针性能更高，还有一些场景必须使用指针，所以实际工作中还是要分场景合理使用
最后
常见的go 逃逸分析差不多就是这些了，虽然go会自动管理内存，减小了写代码的负担，但是想要写出高效可靠的代码还是有一些细节有注意的。