寫過C/C++的同學都知道，調用著名的malloc和new函數可以在堆上分配一塊記憶體，這塊記憶體的使用和銷毀的責任都在程式員。一不小心，就會發生記憶體泄露，搞得膽戰心驚。切換到Golang後，基本不會擔心記憶體泄露了。雖然也有new函數，但是使用new函數得到的記憶體不一定就在堆上。逃逸分析告訴你變數到底去... ...

寫過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”和“RELEASSE”，分配和釋放；而堆分配記憶體首先需要去找到一塊大小合適的記憶體塊，之後要通過垃圾回收才能釋放。

通過逃逸分析，可以儘量把那些不需要分配到堆上的變數直接分配到棧上，堆上的變數少了，會減輕分配堆記憶體的開銷，同時也會減少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{})，編譯期間很難確定其參數的具體類型，也會發生逃逸。

使用反彙編命令也可以看出變數是否發生逃逸。