Golang之變數去哪兒？

Stefno發表於2019-03-01

寫過 C/C++ 的同學都知道，呼叫著名的 malloc 和 new 函式可以在堆上分配一塊記憶體，這塊記憶體的使用和銷燬的責任都在程式設計師。一不小心，就會發生記憶體洩露，搞得膽戰心驚。

切換到 Golang 後，基本不會擔心記憶體洩露了。雖然也有 new 函式，但是使用 new 函式得到的記憶體不一定就在堆上。堆和棧的區別對程式設計師 “模糊化” 了，當然這一切都是 Go 編譯器在背後幫我們完成的。

一個變數是在堆上分配，還是在棧上分配，是經過編譯器的逃逸分析之後得出的結論。

這篇文章，就將帶領大家一起去探索逃逸分析——變數到底去哪兒，堆還是棧？

什麼是逃逸分析

以前寫 C/C++ 程式碼時，為了提高效率，常常將pass-by-value（傳值）“升級” 成pass-by-reference，企圖避免建構函式的執行，並且直接返回一個指標。

你一定還記得，這裡隱藏了一個很大的坑：在函式內部定義了一個區域性變數，然後返回這個區域性變數的地址（指標）。這些區域性變數是在棧上分配的（靜態記憶體分配），一旦函式執行完畢，變數佔據的記憶體會被銷燬，任何對這個返回值作的動作（如解引用），都將擾亂程式的執行，甚至導致程式直接崩潰。比如下面的這段程式碼：

int *foo ( void )   
{   
    int t = 3;
    return &amp;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！

簡單來說，編譯器會根據變數是否被外部引用來決定是否逃逸：

> 1. 如果函式外部沒有引用，則優先放到棧中； > 2. 如果函式外部存在引用，則必定放到堆中；

針對第一條，可能放到堆上的情形：定義了一個很大的陣列，需要申請的記憶體過大，超過了棧的儲存能力。

逃逸分析例項

Go 提供了相關的命令，可以檢視變數是否發生逃逸。

還是用上面我們提到的例子：

package main

import &quot;fmt&quot;

func foo() *int {
    t := 3
    return &amp;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: &amp;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{})，編譯期間很難確定其引數的具體型別，也會發生逃逸。

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