1.逃逸分析

在 C/C++ 中，可以通过调用 malloc 函数或使用 new 运算符从堆上分配到一块内存，该内存的使用、销毁的责任都在程序员，一不小心就会发生内存泄漏，使程序员胆战心惊；而在 Go 语言中，程序员们基本上不需要再担心内存泄漏了，虽然 Go 也有内建函数 new，但调用 new 函数得到的内存不一定在堆上，还有可能在栈上，这是因为在 Go 语言中，堆和栈的区别被“模糊化”了，当然这一切都是 Go 编译器在后台完成的，一个变量是在堆上分配还是在栈上分配，是经过编译器的逃逸分析之后得出的“结论”——如果变量的生命周期超出了函数栈帧的范围（例如返回了指向该变量的指针），编译器就会将其“逃逸”到堆上分配，否则优先分配在栈上，函数返回时自动回收，这种机制让 Go 程序员既能享受灵活的内存操作，又无需手动管理内存释放，大大降低了内存泄漏的风险。

1.1 逃逸分析是什么？

在编写 C/C++ 代码时，为了提高效率，经常会将返回值修改成返回指针，企图避免构造函数的开销。其实这里隐藏了一个陷阱：在函数内部定义了一个局部变量，函数结束时返回这个局部变量的地址（指针）。因为这些局部变量是在栈上分配的（即静态内存分配），函数一旦执行完毕，变量占据的内存空间会被销毁，任何对这个返回值做的操作（如解引用），都将扰乱程序的运行，甚至导致程序直接崩溃。比如下面的这段代码：int* foo() { int t = 3; return &t; }。有些人可能知道上面这个陷阱，做了一些改进：在函数内部使用 new 运算符构造一个变量（即动态内存分配），然后返回此变量的地址。因为变量是在堆上创建的，所以在函数退出时不会被销毁，改进后的代码如下：int* foo() { int* t = new int; *t = 3; return t; }。但是，这样就行了吗？新建出来的对象该在何时何地删除呢？调用者可能会忘记删除或者直接将返回值传给其他函数，之后就再也不能删除它了，也就发生了所谓的内存泄漏。C++ 是公认的语法最复杂的语言，据说没有人可以完全掌握它的语法。而这一切在 Go 语言中就大不相同了，像上面示例的 C++ 代码放到 Go 里没有任何问题：func foo() *int { t := new(int); *t = 3; return t }。“你表面的光鲜，一定是背后有很多人在支撑”，放到 Go 语言里就是指编译器的逃逸分析：它是编译器执行静态代码分析后，对内存管理进行的优化和简化。在编译原理中，分析指针动态范围的方法被称之为逃逸分析。通俗来讲，当一个对象的指针被多个方法或线程引用时，则称这个指针发生了逃逸。逃逸分析决定一个变量是分配在堆上还是分配在栈上。在 Go 中，编译器通过逃逸分析判断变量的生命周期是否超出了函数栈帧的范围：如果变量在函数返回后仍可能被引用（比如通过返回指针或将其传递给外部），编译器就会将它“逃逸”到堆上分配；否则优先分配在栈上，函数返回时自动回收。这种机制让 Go 程序员既能享受像 C/C++ 一样的灵活指针操作，又无需手动管理内存的释放，大大降低了内存泄漏的风险。

1.2 逃逸分析有什么作用？

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

逃逸分析把变量合理地分配到它该去的地方，“找准自己的位置”。即使是用 new 函数申请到的内存，如果编译器发现这块内存在退出函数后就没有使用了，那就分配到栈上，毕竟栈上的内存分配比堆上快很多；反之，即使表面上只是一个普通的变量，但是经过编译器的逃逸分析后发现，
在函数之外还有其他的地方在引用，那就分配到堆上。真正地做到“按需分配”。

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

堆和栈相比，堆适合不可预知大小的内存分配。但是为此付出的代价是分配速度较慢，而且会形成内存碎片；栈内存分配则会非常快。栈分配内存只需要通过 PUSH 指令，并且会被自动释放；而堆分配内存首先需要去找到一个大小合适的内存块，之后要通过垃圾回收才能释放。通过逃逸分析，可以尽量把那些不需要分配到堆上的变量直接分配到栈上，堆上的变量少了，会减轻堆内存分配的开销，同时也会减少垃圾回收（Garbage Collection，GC）的压力，提高程序的运行速度

1.3 逃逸分析是怎么完成的

原则是：如果一个函数返回对一个变量的引用，那么这个变量就会发生逃逸。编译器会分析代码特征和代码的生命周期，Go中的变量只有编译器可以证明在函数返回后不会再被引用，才分配到栈上，其他情况都是分配到堆上。

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

对一个变量取地址，可能会被分配到堆上。但是编译器进行逃逸分析后，如果考虑到在函数返回后，此变量不会被引用，那么还是会被分配到栈上。简单来说，编译器会根据变量是否被外部引用来决定是否逃逸：
1）如果变量在函数外部没有引用，则优先放到栈上。
2）如果变量在函数外部存在引用，则必定放到堆上。
针对第一条，放到堆上的情形：定义了一个很大的数组，需要申请的内存过大，超过了栈的存储能力。

GO与C/C++中的堆和栈是同一个概念嘛

在前面的分析中，其实隐式地默认了所提及 Go 中堆和栈这些概念与 C/C++ 中堆和栈的概念是同一种事物。但读者应该需要进一步认识到这里面的区别。

首先要明确，C/C++ 中提及的“程序堆栈”本质上其实是操作系统层级的概念，它通过 C/C++ 语言的编译器和所在的系统环境来共同决定。在程序启动时，操作系统会自动维护一个所启动程序消耗内存的地址空间，并自动将这个空间从逻辑上划分为堆内存空间和栈内存空间。这时，“栈”的概念是指程序运行时自动获得的一小块内存，而后续的函数调用所消耗的栈大小，会在编译期间由编译器决定，用于保存局部变量或者保存函数调用栈。如果在 C/C++ 中声明一个局部变量，则会执行逻辑上的压栈操作，在栈中记录局部变量。而当局部变量离开作用域之后，所谓的自动释放本质上是该位置的内存在下一次函数调用压栈的过程中，可以被无条件的覆盖；对于堆而言，每当程序通过系统调用向操作系统申请内存时，会将所需的空间从维护的堆内存地址空间中分配出去，而在归还时则会将归还的内存合并到所维护的地址空间中。

Go 程序也是运行在操作系统上的程序，自然同样拥有前面提及的堆和栈的概念。但区别在于传统意义上的“栈”被 Go 语言的运行时全部消耗了，用于维护运行时各个组件之间的协调，例如调度器、垃圾回收、系统调用等。而对于用户态的 Go 代码而言，它们所消耗的“堆和栈”，其实只是 Go 运行时通过管理向操作系统申请的堆内存，构造的逻辑上的“堆和栈”，它们的本质都是从操作系统申请而来的堆内存。由于用户态 Go 程序的“栈空间”是由运行时管理堆内存得来，相较于只有 1MB 的 C/C++ 中的“栈”而言，Go 程序拥有“几乎”无限的栈内存（1GB）。更进一步，对于用户态 Go 代码消耗的栈，Go 语言运行时会为了防止内存碎片化，会在适当的时候对整个栈进行深拷贝，将其整个复制到另一块内存区域（当然，这个过程对用户态的代码是不可见的），这也是相较于传统意义上栈是一块固定分配好的内存所出现的另一处差异。也正是由于这个特点的存在，指针的算术运算不再能奏效，因为在没有特殊说明的情况下，无法确定运算前后指针所指向的地址的内容是否已经被 Go 运行时移动。