逃逸分析

by 夏泽民 Feb 5, 2020

对于手动管理内存的语言，比如 C/C++，调用著名的malloc和new函数可以在堆上分配一块内存，这块内存的使用和销毁的责任都在程序员。一不小心，就会发生内存泄露，搞得胆战心惊。
但是 Golang 并不是这样，虽然 Golang 语言里面也有 new。Golang 编译器决定变量应该分配到什么地方时会进行逃逸分析。使用new函数得到的内存不一定就在堆上。堆和栈的区别对程序员“模糊化”了，当然这一切都是Go编译器在背后帮我们完成的。一个变量是在堆上分配，还是在栈上分配，是经过编译器的逃逸分析之后得出的结论。

一、逃逸分析是什么
wiki定义
In compiler optimization, escape analysis is a method for determining the dynamic scope of pointers - where in the program a pointer can be accessed. It is related to pointer analysis and shape analysis.
When a variable (or an object) is allocated in a subroutine, a pointer to the variable can escape to other threads of execution, or to calling subroutines. If an implementation uses tail call optimization (usually required for functional languages), objects may also be seen as escaping to called subroutines. If a language supports first-class continuations (as do Scheme and Standard ML of New Jersey), portions of the call stack may also escape.
If a subroutine allocates an object and returns a pointer to it, the object can be accessed from undetermined places in the program — the pointer has “escaped”. Pointers can also escape if they are stored in global variables or other data structures that, in turn, escape the current procedure.
Escape analysis determines all the places where a pointer can be stored and whether the lifetime of the pointer can be proven to be restricted only to the current procedure and/or threa.

C/C++中，有时为了提高效率，常常将pass-by-value（传值）“升级”成pass-by-reference，企图避免构造函数的运行，并且直接返回一个指针。然而这里隐藏了一个很大的坑：在函数内部定义了一个局部变量，然后返回这个局部变量的地址（指针）。这些局部变量是在栈上分配的（静态内存分配），一旦函数执行完毕，变量占据的内存会被销毁，任何对这个返回值作的动作（如解引用），都将扰乱程序的运行，甚至导致程序直接崩溃。例如：

int *foo ( void )

{

int t = 3;
return &t;
}
为了避免这个坑，有个更聪明的做法：在函数内部使用new函数构造一个变量（动态内存分配），然后返回此变量的地址。因为变量是在堆上创建的，所以函数退出时不会被销毁。但是，这样就行了吗？new出来的对象该在何时何地delete呢？调用者可能会忘记delete或者直接拿返回值传给其他函数，之后就再也不能delete它了，也就是发生了内存泄露。关于这个坑，大家可以去看看《Effective C++》条款21，讲得非常好！
C++是公认的语法最复杂的语言，据说没有人可以完全掌握C++的语法。而这一切在Go语言中就大不相同了。像上面示例的C++代码放到Go里，没有任何问题。
你表面的光鲜，一定是背后有很多人为你撑起的！Go语言里就是编译器的逃逸分析。它是编译器执行静态代码分析后，对内存管理进行的优化和简化。
在编译原理中，分析指针动态范围的方法称之为逃逸分析。通俗来讲，当一个对象的指针被多个方法或线程引用时，我们称这个指针发生了逃逸。
更简单来说，逃逸分析决定一个变量是分配在堆上还是分配在栈上。

二、为什么要逃逸分析
前面讲的C/C++中出现的问题，在Go中作为一个语言特性被大力推崇。真是C/C++之砒霜Go之蜜糖！
C/C++中动态分配的内存需要我们手动释放，导致猿们平时在写程序时，如履薄冰。这样做有他的好处：程序员可以完全掌控内存。但是缺点也是很多的：经常出现忘记释放内存，导致内存泄露。所以，很多现代语言都加上了垃圾回收机制。
Go的垃圾回收，让堆和栈对程序员保持透明。真正解放了程序员的双手，让他们可以专注于业务，“高效”地完成代码编写。把那些内存管理的复杂机制交给编译器，而程序员可以去享受生活。
逃逸分析这种“骚操作”把变量合理地分配到它该去的地方，“找准自己的位置”。即使你是用new申请到的内存，如果我发现你竟然在退出函数后没有用了，那么就把你丢到栈上，毕竟栈上的内存分配比堆上快很多；反之，即使你表面上只是一个普通的变量，但是经过逃逸分析后发现在退出函数之后还有其他地方在引用，那我就把你分配到堆上。真正地做到“按需分配”，提前实现共产主义！
如果变量都分配到堆上，堆不像栈可以自动清理。它会引起Go频繁地进行垃圾回收，而垃圾回收会占用比较大的系统开销（占用CPU容量的25%）。
堆和栈相比，堆适合不可预知大小的内存分配。但是为此付出的代价是分配速度较慢，而且会形成内存碎片。栈内存分配则会非常快。栈分配内存只需要两个CPU指令：“PUSH”和“RELEASE”，分配和释放；而堆分配内存首先需要去找到一块大小合适的内存块，之后要通过垃圾回收才能释放。
通过逃逸分析，可以尽量把那些不需要分配到堆上的变量直接分配到栈上，堆上的变量少了，会减轻分配堆内存的开销，同时也会减少gc的压力，提高程序的运行速度。

三、逃逸分析如何完成
Go逃逸分析最基本的原则是：如果一个函数返回对一个变量的引用，那么它就会发生逃逸。
简单来说，编译器会分析代码的特征和代码生命周期，Go中的变量只有在编译器可以证明在函数返回后不会再被引用的，才分配到栈上，其他情况下都是分配到堆上。
Go语言里没有一个关键字或者函数可以直接让变量被编译器分配到堆上，相反，编译器通过分析代码来决定将变量分配到何处。
对一个变量取地址，可能会被分配到堆上。但是编译器进行逃逸分析后，如果考察到在函数返回后，此变量不会被引用，那么还是会被分配到栈上。
简单来说，编译器会根据变量是否被外部引用来决定是否逃逸：
1）如果函数外部没有引用，则优先放到栈中；
2）如果函数外部存在引用，则必定放到堆中；
针对第一条，可能放到堆上的情形：定义了一个很大的数组，需要申请的内存过大，超过了栈的存储能力。

四、逃逸分析实例
下面是一个简单的例子。

package main

import ()

func foo() *int {
var x int
return &x
}

func bar() int {
x := new(int)
*x = 1
return *x
}

func main() {}
开启逃逸分析日志很简单，只要在编译的时候加上-gcflags ‘-m’，但是我们为了不让编译时自动内连函数，一般会加-l参数，最终为-gcflags ‘-m -l’，执行如下命令：

$ go build -gcflags ‘-m -l’ main.go

command-line-arguments

./main.go:5:9: &x escapes to heap
./main.go:4:6: moved to heap: x
./main.go:9:10: bar new(int) does not escape
上面代码中foo() 中的 x 最后在堆上分配，而 bar() 中的 x 最后分配在了栈上。
也可以使用反汇编命令看出变量是否发生逃逸。

$ go tool compile -S main.go
截取部分结果，图中标记出来的说明foo中x是在堆上分配内存，发生了逃逸。
反汇编命令结果
什么时候逃逸呢？golang.org FAQ 上有一个关于变量分配的问题如下：

Q: How do I know whether a variable is allocated on the heap or the stack?
A: From a correctness standpoint, you don’t need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.
The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function’s stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.
In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

关于什么时候逃逸，什么时候不逃逸，我们接下来再看几个小例子。

1）Example1
package main
type S struct{}
func main() {
var x S
y := &x
_ = *identity(y)
}
func identity(z *S) *S {
return z
}
结果如下：

command-line-arguments

./main.go:8:22: leaking param: z to result ~r1 level=0
./main.go:5:7: main &x does not escape
这里的第一行表示z变量是“流式”，因为identity这个函数仅仅输入一个变量，又将这个变量作为返回输出，但identity并没有引用z，所以这个变量没有逃逸，而x没有被引用，且生命周期也在mian里，x没有逃逸，分配在栈上。

2）Example2
package main
type S struct{}
func main() {
var x S
_ = *ref(x)
}
func ref(z S) *S {
return &z
}
结果如下：

command-line-arguments

./main.go:8:9: &z escapes to heap
./main.go:7:16: moved to heap: z
这里的z是逃逸了，原因很简单，go都是值传递，ref函数copy了x的值，传给z，返回z的指针，然后在函数外被引用，说明z这个变量在函数內声明，可能会被函数外的其他程序访问。所以z逃逸了，分配在堆上

3）Example3
package main
type S struct {
M *int
}
func main() {
var i int
refStruct(i)
}
func refStruct(y int) (z S) {
z.M = &y
return z
}
结果如下：

command-line-arguments

./main.go:10:8: &y escapes to heap
./main.go:9:26: moved to heap: y
看日志的输出，这里的y是逃逸了，看来在struct里好像并没有区别，有可能被函数外的程序访问就会逃逸

4）Example4
package main
type S struct {
M *int
}
func main() {
var i int
refStruct(&i)
}
func refStruct(y *int) (z S) {
z.M = y
return z
}
结果如下：

command-line-arguments

./main.go:9:27: leaking param: y to result z level=0
./main.go:7:12: main &i does not escape
这里的y没有逃逸，分配在栈上，原因和Example1是一样的。

5）Example5
package main
type S struct {
M *int
}
func main() {
var x S
var i int
ref(&i, &x)
}
func ref(y *int, z *S) {
z.M = y
}
结果如下：

command-line-arguments

./main.go:10:21: leaking param: y
./main.go:10:21: ref z does not escape
./main.go:8:6: &i escapes to heap
./main.go:7:6: moved to heap: i
./main.go:8:10: main &x does not escape
这里的z没有逃逸，而i却逃逸了，这是因为go的逃逸分析不知道z和i的关系，逃逸分析不知道参数y是z的一个成员，所以只能把它分配给堆。

编译优化
本节介绍Go编译器执行的三个重要优化。

逃逸分析
内联
死码消除
Go 编译器的历史
Go 编译器在2007年左右开始作为 Plan9 编译器工具链的一个分支。当时的编译器与 Aho 和 Ullman 的 Dragon Book 非常相似。

2015年，当时的 Go 1.5 编译器从 C 机械地翻译成 Go。

一年后，Go 1.7 引入了一个基于 SSA 技术的新编译器后端，取代了之前的 Plan 9风格的代码。这个新的后端为泛型和体系结构特定的优化提供了许多可能。

逃逸分析
我们要讨论的第一个优化是逃逸分析。

为了说明逃逸分析，首先让我们来回忆一下在 Go spec 中没有提到堆和栈，它只提到 Go 语言是有垃圾回收的，但也没有说明如何是如何实现的。

一个遵循 Go spec 的 Go 实现可以将每个分配操作都在堆上执行。这会给垃圾回收器带来很大压力，但这样做是绝对错误的 – 多年来，gccgo对逃逸分析的支持非常有限，所以才导致这样做被认为是有效的。

然而，goroutine 的栈是作为存储局部变量的廉价场所而存在；没有必要在栈上执行垃圾回收。因此，在栈上分配内存也是更加安全和有效的。

在一些语言中，如C和C++，在栈还是堆上分配内存由程序员手动决定——堆分配使用malloc 和free，而栈分配通过alloca。错误地使用这种机制会是导致内存错误的常见原因。

在 Go 中，如果一个值超过了函数调用的生命周期，编译器会自动将之移动到堆中。我们管这种现象叫：该值逃逸到了堆。

type Foo struct {
a, b, c, d int
}

func NewFoo() *Foo {
return &Foo{a: 3, b: 1, c: 4, d: 7}
}
在这个例子中，NewFoo 函数中分配的 Foo 将被移动到堆中，因此在 NewFoo 返回后 Foo 仍然有效。

这是从早期的 Go 就开始有的。与其说它是一种优化，不如说它是一种自动正确性特性。无法在 Go 中返回栈上分配的变量的地址。

同时编译器也可以做相反的事情；它可以找到堆上要分配的东西，并将它们移动到栈上。

逃逸分析 - 例1
让我们来看下面的例子：

// Sum 函数返回 0-100 的整数之和
func Sum() int {
const count = 100
numbers := make([]int, count)
for i := range numbers {
numbers[i] = i + 1
}

    var sum int

    for _, i := range numbers {

            sum += i

    }

    return sum } Sum 将 0-100 的 ints型数字相加并返回结果。

因为 numbers 切片仅在 Sum函数内部使用，编译器将在栈上存储这100个整数而不是堆。也没有必要对 numbers进行垃圾回收，因为它会在 Sum 返回时自动释放。

调查逃逸分析
证明它！

要打印编译器关于逃逸分析的决策，请使用-m标志。

% go build -gcflags=-m examples/esc/sum.go

command-line-arguments

examples/esc/sum.go:8:17: Sum make([]int, count) does not escape
examples/esc/sum.go:22:13: answer escapes to heap
examples/esc/sum.go:22:13: main … argument does not escape
第8行显示编译器已正确推断 make([]int, 100)的结果不会逃逸到堆。

第22行显示answer逃逸到堆的原因是fmt.Println是一个可变函数。可变参数函数的参数被装入一个切片，在本例中为[]interface{}，所以会将answer赋值为接口值，因为它是通过调用fmt.Println引用的。从 Go 1.6（可能是）开始，垃圾收集器需要通过接口传递的所有值都是指针，编译器看到的是这样的：

var answer = Sum()
fmt.Println([]interface{&answer}…)
我们可以使用标识 -gcflags=”-m -m” 来确定这一点。会返回：

examples/esc/sum.go:22:13: answer escapes to heap
examples/esc/sum.go:22:13: from … argument (arg to …) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: from *(… argument) (indirection) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: from … argument (passed to call[argument content escapes]) at examples/esc/sum.go:22:13
examples/esc/sum.go:22:13: main … argument does not escape
总之，不要担心第22行，这对我们的讨论并不重要。

逃逸分析 - 例2
这个例子是我们模拟的。它不是真正的代码，只是一个例子。

package main

import “fmt”

type Point struct{ X, Y int }

const Width = 640
const Height = 480

func Center(p *Point) {
p.X = Width / 2
p.Y = Height / 2
}

func NewPoint() {
p := new(Point)
Center(p)
fmt.Println(p.X, p.Y)
}
NewPoint 创建了一个 *Point 指针值 p。我们将p传递给Center函数，该函数将点移动到屏幕中心的位置。最后我们打印出 p.X 和 p.Y 的值。

% go build -gcflags=-m examples/esc/center.go

command-line-arguments

examples/esc/center.go:10:6: can inline Center
examples/esc/center.go:17:8: inlining call to Center
examples/esc/center.go:10:13: Center p does not escape
examples/esc/center.go:18:15: p.X escapes to heap
examples/esc/center.go:18:20: p.Y escapes to heap
examples/esc/center.go:16:10: NewPoint new(Point) does not escape
examples/esc/center.go:18:13: NewPoint … argument does not escape

command-line-arguments

尽管p是使用new分配的，但它不会存储在堆上，因为Center被内联了，所以没有p的引用会逃逸到Center函数。

内联
在 Go 中，函数调用有固定的开销；栈和抢占检查。

硬件分支预测器改善了其中的一些功能，但就功能大小和时钟周期而言，这仍然是一个成本。

内联是避免这些成本的经典优化方法。

内联只对叶子函数有效，叶子函数是不调用其他函数的。这样做的理由是:

如果你的函数做了很多工作，那么前序开销可以忽略不计。
另一方面，小函数为相对较少的有用工作付出固定的开销。这些是内联目标的功能，因为它们最受益。
还有一个原因就是严重的内联会使得堆栈信息更加难以跟踪。

内联 - 例1
func Max(a, b int) int {
if a > b {
return a
}
return b
}

func F() {
const a, b = 100, 20
if Max(a, b) == b {
panic(b)
}
}
我们再次使用 -gcflags = -m 标识来查看编译器优化决策。

% go build -gcflags=-m examples/max/max.go

command-line-arguments

examples/max/max.go:3:6: can inline Max
examples/max/max.go:12:8: inlining call to Max
编译器打印了两行信息：

首先第3行，Max的声明告诉我们它可以内联
其次告诉我们，Max的主体已经内联到第12行调用者中。
内联是什么样的？
编译 max.go 然后我们看看优化版本的 F() 变成什么样了。

% go build -gcflags=-S examples/max/max.go 2>&1 | grep -A5 ‘”“.F STEXT’
““.F STEXT nosplit size=1 args=0x0 locals=0x0
0x0000 00000 (/Users/dfc/devel/gophercon2018-performance-tuning-workshop/4-compiler-optimisations/examples/max/max.go:10) TEXT ““.F(SB), NOSPLIT, $0-0
0x0000 00000 (/Users/dfc/devel/gophercon2018-performance-tuning-workshop/4-compiler-optimisations/examples/max/max.go:10) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0000 00000 (/Users/dfc/devel/gophercon2018-performance-tuning-workshop/4-compiler-optimisations/examples/max/max.go:10) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0000 00000 () RET
0x0000 c3
一旦Max被内联到这里，这就是F的主体 - 这个函数什么都没干。我知道屏幕上有很多没用的文字，但是相信我的话，唯一发生的就是RET。实际上F变成了:

func F() {
return
}
注意 : 利用 -S 的输出并不是进入二进制文件的最终机器码。链接器在最后的链接阶段进行一些处理。像FUNCDATA和PCDATA这样的行是垃圾收集器的元数据，它们在链接时移动到其他位置。如果你正在读取-S的输出，请忽略FUNCDATA和PCDATA行；它们不是最终二进制的一部分。

调整内联级别
使用-gcflags=-l标识调整内联级别。有些令人困惑的是，传递一个-l将禁用内联，两个或两个以上将在更激进的设置中启用内联。

-gcflags=-l，禁用内联。
什么都不做，常规的内联
-gcflags=’-l -l’ 内联级别2，更积极，可能更快，可能会制作更大的二进制文件。
-gcflags=’-l -l -l’ 内联级别3，再次更加激进，二进制文件肯定更大，也许更快，但也许会有 bug。
-gcflags=-l=4 (4个 -l) 在 Go 1.11 中将支持实验性的中间栈内联优化。
死码消除
为什么a和b是常数很重要?

为了理解发生了什么，让我们看一下编译器在把Max内联到F中的时候看到了什么。我们不能轻易地从编译器中获得这个，但是直接手动完成它。

Before:

func Max(a, b int) int {
if a > b {
return a
}
return b
}

func F() {
const a, b = 100, 20
if Max(a, b) == b {
panic(b)
}
}
After:

func F() {
const a, b = 100, 20
var result int
if a > b {
result = a
} else {
result = b
}
if result == b {
panic(b)
}
}
因为a和b是常量，所以编译器可以在编译时证明分支永远不会是假的；100总是大于20。因此它可以进一步优化 F 为

func F() {
const a, b = 100, 20
var result int
if true {
result = a
} else {
result = b
}
if result == b {
panic(b)
}
}
既然分支的结果已经知道了，那么结果的内容也就知道了。这叫做分支消除。

func F() {
const a, b = 100, 20
const result = a
if result == b {
panic(b)
}
}
现在分支被消除了，我们知道结果总是等于a，并且因为a是常数，我们知道结果是常数。编译器将此证明应用于第二个分支

func F() {
const a, b = 100, 20
const result = a
if false {
panic(b)
}
}
并且再次使用分支消除，F的最终形式减少成这样。

func F() {
const a, b = 100, 20
const result = a
}
最后就变成

func F() {
}
死码消除（续）
分支消除是一种被称为死码消除的优化。实际上，使用静态证明来表明一段代码永远不可达，通常称为死代码，因此它不需要在最终的二进制文件中编译、优化或发出。

我们发现死码消除与内联一起工作，以减少循环和分支产生的代码数量，这些循环和分支被证明是不可到达的。

你可以利用这一点来实现昂贵的调试，并将其隐藏起来

const debug = false
结合构建标记，这可能非常有用。

进一步阅读
Using // +build to switch between debug and release builds
How to use conditional compilation with the go build tool
编译器标识练习
编译器标识提供如下：

go build -gcflags=$FLAGS
研究以下编译器功能的操作：

-S 打印正在编译的包的汇编代码
-l 控制内联行为； -l 禁止内联， -l -l 增加-l（更多-l会增加编译器对代码内联的强度）。试验编译时间，程序大小和运行时间的差异。
-m 控制优化决策的打印，如内联，逃逸分析。-m打印关于编译器的想法的更多细节。
-l -N 禁用所有优化。
注意 : If you find that subsequent runs of go build … produce no output, delete the ./max binary in your working directory.

什么是逃逸分析
为什么要逃逸分析
逃逸分析是怎么完成的
逃逸分析实例
总结
写过C/C++的同学都知道，调用著名的malloc和new函数可以在堆上分配一块内存，这块内存的使用和销毁的责任都在程序员。一不小心，就会发生内存泄露，搞得胆战心惊。

切换到Golang后，基本不会担心内存泄露了。虽然也有new函数，但是使用new函数得到的内存不一定就在堆上。堆和栈的区别对程序员“模糊化”了，当然这一切都是Go编译器在背后帮我们完成的。

一个变量是在堆上分配，还是在栈上分配，是经过编译器的逃逸分析之后得出的结论。

这篇文章，就将带领大家一起去探索逃逸分析——变量到底去哪儿，堆还是栈？

什么是逃逸分析
以前写C/C++代码时，为了提高效率，常常将pass-by-value（传值）“升级”成pass-by-reference，企图避免构造函数的运行，并且直接返回一个指针。

你一定还记得，这里隐藏了一个很大的坑：在函数内部定义了一个局部变量，然后返回这个局部变量的地址（指针）。这些局部变量是在栈上分配的（静态内存分配），一旦函数执行完毕，变量占据的内存会被销毁，任何对这个返回值作的动作（如解引用），都将扰乱程序的运行，甚至导致程序直接崩溃。比如下面的这段代码：

int *foo ( void )

{

int t = 3;
return &t;
}
有些同学可能知道上面这个坑，用了个更聪明的做法：在函数内部使用new函数构造一个变量（动态内存分配），然后返回此变量的地址。因为变量是在堆上创建的，所以函数退出时不会被销毁。但是，这样就行了吗？new出来的对象该在何时何地delete呢？调用者可能会忘记delete或者直接拿返回值传给其他函数，之后就再也不能delete它了，也就是发生了内存泄露。关于这个坑，大家可以去看看《Effective C++》条款21，讲得非常好！

C++是公认的语法最复杂的语言，据说没有人可以完全掌握C++的语法。而这一切在Go语言中就大不相同了。像上面示例的C++代码放到Go里，没有任何问题。

你表面的光鲜，一定是背后有很多人为你撑起的！Go语言里就是编译器的逃逸分析。它是编译器执行静态代码分析后，对内存管理进行的优化和简化。

在编译原理中，分析指针动态范围的方法称之为逃逸分析。通俗来讲，当一个对象的指针被多个方法或线程引用时，我们称这个指针发生了逃逸。

更简单来说，逃逸分析决定一个变量是分配在堆上还是分配在栈上。

为什么要逃逸分析
前面讲的C/C++中出现的问题，在Go中作为一个语言特性被大力推崇。真是C/C++之砒霜Go之蜜糖！

C/C++中动态分配的内存需要我们手动释放，导致猿们平时在写程序时，如履薄冰。这样做有他的好处：程序员可以完全掌控内存。但是缺点也是很多的：经常出现忘记释放内存，导致内存泄露。所以，很多现代语言都加上了垃圾回收机制。

Go的垃圾回收，让堆和栈对程序员保持透明。真正解放了程序员的双手，让他们可以专注于业务，“高效”地完成代码编写。把那些内存管理的复杂机制交给编译器，而程序员可以去享受生活。

逃逸分析这种“骚操作”把变量合理地分配到它该去的地方，“找准自己的位置”。即使你是用new申请到的内存，如果我发现你竟然在退出函数后没有用了，那么就把你丢到栈上，毕竟栈上的内存分配比堆上快很多；反之，即使你表面上只是一个普通的变量，但是经过逃逸分析后发现在退出函数之后还有其他地方在引用，那我就把你分配到堆上。真正地做到“按需分配”，提前实现共产主义！

如果变量都分配到堆上，堆不像栈可以自动清理。它会引起Go频繁地进行垃圾回收，而垃圾回收会占用比较大的系统开销（占用CPU容量的25%）。

堆和栈相比，堆适合不可预知大小的内存分配。但是为此付出的代价是分配速度较慢，而且会形成内存碎片。栈内存分配则会非常快。栈分配内存只需要两个CPU指令：“PUSH”和“RELEASE”，分配和释放；而堆分配内存首先需要去找到一块大小合适的内存块，之后要通过垃圾回收才能释放。

通过逃逸分析，可以尽量把那些不需要分配到堆上的变量直接分配到栈上，堆上的变量少了，会减轻分配堆内存的开销，同时也会减少gc的压力，提高程序的运行速度。

逃逸分析是怎么完成的
Go逃逸分析最基本的原则是：如果一个函数返回对一个变量的引用，那么它就会发生逃逸。

简单来说，编译器会分析代码的特征和代码生命周期，Go中的变量只有在编译器可以证明在函数返回后不会再被引用的，才分配到栈上，其他情况下都是分配到堆上。

Go语言里没有一个关键字或者函数可以直接让变量被编译器分配到堆上，相反，编译器通过分析代码来决定将变量分配到何处。

对一个变量取地址，可能会被分配到堆上。但是编译器进行逃逸分析后，如果考察到在函数返回后，此变量不会被引用，那么还是会被分配到栈上。套个取址符，就想骗补助？Too young！

简单来说，编译器会根据变量是否被外部引用来决定是否逃逸：

如果函数外部没有引用，则优先放到栈中；
如果函数外部存在引用，则必定放到堆中；
针对第一条，可能放到堆上的情形：定义了一个很大的数组，需要申请的内存过大，超过了栈的存储能力。

逃逸分析实例
Go提供了相关的命令，可以查看变量是否发生逃逸。

还是用上面我们提到的例子：

package main

import “fmt”

func foo() *int {
t := 3
return &t;
}

func main() {
x := foo()
fmt.Println(*x)
}
foo函数返回一个局部变量的指针，main函数里变量x接收它。执行如下命令：

go build -gcflags ‘-m -l’ main.go
加-l是为了不让foo函数被内联。得到如下输出：

command-line-arguments

src/main.go:7:9: &t escapes to heap
src/main.go:6:7: moved to heap: t
src/main.go:12:14: *x escapes to heap
src/main.go:12:13: main … argument does not escape
foo函数里的变量t逃逸了，和我们预想的一致。让我们不解的是为什么main函数里的x也逃逸了？这是因为有些函数参数为interface类型，比如fmt.Println(a …interface{})，编译期间很难确定其参数的具体类型，也会发生逃逸。

使用反汇编命令也可以看出变量是否发生逃逸。

go tool compile -S main.go
截取部分结果，图中标记出来的说明t是在堆上分配内存，发生了逃逸。

总结
堆上动态分配内存比栈上静态分配内存，开销大很多。

变量分配在栈上需要能在编译期确定它的作用域，否则会分配到堆上。

Go编译器会在编译期对考察变量的作用域，并作一系列检查，如果它的作用域在运行期间对编译器一直是可知的，那么就会分配到栈上。

简单来说，编译器会根据变量是否被外部引用来决定是否逃逸。对于Go程序员来说，编译器的这些逃逸分析规则不需要掌握，我们只需通过go build -gcflags ‘-m’命令来观察变量逃逸情况就行了。

不要盲目使用变量的指针作为函数参数，虽然它会减少复制操作。但其实当参数为变量自身的时候，复制是在栈上完成的操作，开销远比变量逃逸后动态地在堆上分配内存少的多。

最后，尽量写出少一些逃逸的代码，提升程序的运行效率。

Category golang