變量和棧有什么關系

棧可用于內存分配，棧的分配和回收速度非常快。下面代碼展示棧在內存分配上的作用，代碼如下：

func calc(a, b int) int {var c intc = a * bvar x intx = c * 10return x }

代碼說明如下：
第 1 行，傳入 a、b 兩個整型參數。
第 2 行，聲明 c 整型變量，運行時，c 會分配一段內存用以存儲 c 的數值。
第 3 行，將 a 和 b 相乘后賦予 c。
第 5 行，聲明 x 整型變量，x 也會被分配一段內存。
第 6 行，讓 c 乘以 10 后存儲到 x 變量中。
第 8 行，返回 x 的值。

上面的代碼在沒有任何優化情況下，會進行 c 和 x 變量的分配過程。Go 語言默認情況下會將 c 和 x 分配在棧上，這兩個變量在 calc() 函數退出時就不再使用，函數結束時，保存 c 和 x 的棧內存再出棧釋放內存，整個分配內存的過程通過棧的分配和回收都會非常迅速。

變量逃逸（Escape Analysis）——自動決定變量分配方式，提高運行效率

堆和棧各有優缺點，該怎么在編程中處理這個問題呢？在 C/C++ 語言中，需要開發者自己學習如何進行內存分配，選用怎樣的內存分配方式來適應不同的算法需求。比如，函數局部變量盡量使用棧；全局變量、結構體成員使用堆分配等。程序員不得不花費很多年的時間在不同的項目中學習、記憶這些概念并加以實踐和使用。

Go 語言將這個過程整合到編譯器中，命名為“變量逃逸分析”。這個技術由編譯器分析代碼的特征和代碼生命期，決定應該如何堆還是棧進行內存分配，即使程序員使用 Go 語言完成了整個工程后也不會感受到這個過程。

逃逸分析
使用下面的代碼來展現 Go 語言如何通過命令行分析變量逃逸，代碼如下：

package mainimport "fmt"// 本函數測試入口參數和返回值情況 func dummy(b int) int {// 聲明一個c賦值進入參數并返回var c intc = breturn c }// 空函數, 什么也不做 func void() {}func main() {// 聲明a變量并打印var a int// 調用void()函數void()// 打印a變量的值和dummy()函數返回fmt.Println(a, dummy(0)) }

代碼說明如下：

• 第 6 行，dummy() 函數擁有一個參數，返回一個整型值，測試函數參數和返回值分析情況。
• 第 9 行，聲明 c 變量，這里演示函數臨時變量通過函數返回值返回后的情況。
• 第 16 行，這是一個空函數，測試沒有任何參數函數的分析情況。
• 第 23 行，在 main() 中聲明 a 變量，測試 main() 中變量的分析情況。
• 第 26 行，調用 void() 函數，沒有返回值，測試 void() 調用后的分析情況。
• 第 29 行，打印 a 和 dummy(0) 的返回值，測試函數返回值沒有變量接收時的分析情況。

接著使用如下命令行運行上面的代碼：

$ go run -gcflags "-m -l" main.go

使用 go run 運行程序時，-gcflags 參數是編譯參數。其中 -m 表示進行內存分配分析，-l 表示避免程序內聯，也就是避免進行程序優化。

運行結果如下：

\# command-line-arguments ./main.go:29:13: a escapes to heap ./main.go:29:22: dummy(0) escapes to heap ./main.go:29:13: main ... argument does not escape 0 0

程序運行結果分析如下：

• 輸出第 2 行告知“main 的第 29 行的變量 a 逃逸到堆”。
• 第 3 行告知“dummy(0)調用逃逸到堆”。由于 dummy() 函數會返回一個整型值，這個值被 fmt.Println 使用后還是會在其聲明后繼續在 main() 函數中存在。
• 第 4 行，這句提示是默認的，可以忽略。

上面例子中變量 c 是整型，其值通過 dummy() 的返回值“逃出”了 dummy() 函數。c 變量值被復制并作為 dummy() 函數返回值返回，即使 c 變量在 dummy() 函數中分配的內存被釋放，也不會影響 main() 中使用 dummy() 返回的值。c 變量使用棧分配不會影響結果。

取地址發生逃逸
下面的例子使用結構體做數據，了解在堆上分配的情況，代碼如下：

package mainimport "fmt"// 聲明空結構體測試結構體逃逸情況 type Data struct { }func dummy() *Data {// 實例化c為Data類型var c Data//返回函數局部變量地址return &c }func main() {fmt.Println(dummy()) }

代碼說明如下：
第 6 行，聲明一個空的結構體做結構體逃逸分析。
第 9 行，將 dummy() 函數的返回值修改為 *Data 指針類型。
第 12 行，將 c 變量聲明為 Data 類型，此時 c 的結構體為值類型。
第 15 行，取函數局部變量 c 的地址并返回。Go 語言的特性允許這樣做。
第 20 行，打印 dummy() 函數的返回值。

執行逃逸分析：

$ go run -gcflags "-m -l" main.go # command-line-arguments ./main.go:15:9: &c escapes to heap ./main.go:12:6: moved to heap: c ./main.go:20:19: dummy() escapes to heap ./main.go:20:13: main ... argument does not escape &{}

注意第 4 行出現了新的提示：將 c 移到堆中。這句話表示，Go 編譯器已經確認如果將 c 變量分配在棧上是無法保證程序最終結果的。如果堅持這樣做，dummy() 的返回值將是 Data 結構的一個不可預知的內存地址。這種情況一般是 C/C++ 語言中容易犯錯的地方：引用了一個函數局部變量的地址。

Go 語言最終選擇將 c 的 Data 結構分配在堆上。然后由垃圾回收器去回收 c 的內存。

原則
在使用 Go 語言進行編程時，Go 語言的設計者不希望開發者將精力放在內存應該分配在棧還是堆上的問題。編譯器會自動幫助開發者完成這個糾結的選擇。但變量逃逸分析也是需要了解的一個編譯器技術，這個技術不僅用于 Go 語言，在 Java 等語言的編譯器優化上也使用了類似的技術。

編譯器覺得變量應該分配在堆和棧上的原則是：
變量是否被取地址。
變量是否發生逃逸

生命周期

變量的生命周期指的是在程序運行期間變量有效存在的時間間隔。對于在包一級聲明的變量來說，它們的生命周期和整個程序的運行周期是一致的。而相比之下，局部變量的聲明周期則是動態的：每次從創建一個新變量的聲明語句開始，直到該變量不再被引用為止，然后變量的存儲空間可能被回收。函數的參數變量和返回值變量都是局部變量。它們在函數每次被調用的時候創建。

例如，下面摘錄的部分代碼片段：

for t := 0.0; t < cycles*2*math.Pi; t += res {x := math.Sin(t)y := math.Sin(t*freq + phase)img.SetColorIndex(size+int(x*size+0.5), size+int(y*size+0.5),blackIndex) }

提示：函數的有右小括弧也可以另起一行縮進，同時為了防止編譯器在行尾自動插入分號而導致的編譯錯誤，可以在末尾的參數變量后面顯式插入逗號。像下面這樣：

for t := 0.0; t < cycles*2*math.Pi; t += res {x := math.Sin(t)y := math.Sin(t*freq + phase)img.SetColorIndex(size+int(x*size+0.5), size+int(y*size+0.5),blackIndex, // 最后插入的逗號不會導致編譯錯誤，這是Go編譯器的一個特性) // 小括弧另起一行縮進，和大括弧的風格保存一致 }

在每次循環的開始會創建臨時變量 t，然后在每次循環迭代中創建臨時變量 x 和 y。

那么 Go語言的自動垃圾收集器是如何知道一個變量是何時可以被回收的呢？這里我們可以避開完整的技術細節，基本的實現思路是，從每個包級的變量和每個當前運行函數的每一個局部變量開始，通過指針或引用的訪問路徑遍歷，是否可以找到該變量。如果不存在這樣的訪問路徑，那么說明該變量是不可達的，也就是說它是否存在并不會影響程序后續的計算結果。

因為一個變量的有效周期只取決于是否可達，因此一個循環迭代內部的局部變量的生命周期可能超出其局部作用域。同時，局部變量可能在函數返回之后依然存在。

編譯器會自動選擇在棧上還是在堆上分配局部變量的存儲空間，但可能令人驚訝的是，這個選擇并不是由用 var 還是 new 聲明變量的方式決定的。

var global *int func f() {var x intx = 1global = &x } func g() {y := new(int)*y = 1 }

f 函數里的 x 變量必須在堆上分配，因為它在函數退出后依然可以通過包一級的 global 變量找到，雖然它是在函數內部定義的；用 Go語言的術語說，這個 x 局部變量從函數 f 中逃逸了。

相反，當 g 函數返回時，變量?*y?將是不可達的，也就是說可以馬上被回收的。因此，*y?并沒有從函數 g 中逃逸，編譯器可以選擇在棧上分配?*y?的存儲空間（譯注：也可以選擇在堆上分配，然后由 Go語言的 GC 回收這個變量的內存空間），雖然這里用的是 new 方式。

其實在任何時候，并不需為了編寫正確的代碼而要考慮變量的逃逸行為，要記住的是，逃逸的變量需要額外分配內存，同時對性能的優化可能會產生細微的影響。

Go語言的自動垃圾收集器對編寫正確的代碼是一個巨大的幫助，但也并不是說你完全不用考慮內存了。雖然不需要顯式地分配和釋放內存，但是要編寫高效的程序你依然需要了解變量的生命周期。例如，如果將指向短生命周期對象的指針保存到具有長生命周期的對象中，特別是保存到全局變量時，會阻止對短生命周期對象的垃圾回收（從而可能影響程序的性能）。

總結

以上是生活随笔為你收集整理的golang逃逸分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。