逃逸分析

引用：https://gocn.vip/article/1763

問題

type User struct { ID int64 Name string Avatar string } func GetUserInfo() *User { return &User{ID: 13746731, Name: "EDDYCJY", Avatar: "https://avatars0.githubusercontent.com/u/13746731"} } func main() { _ = GetUserInfo() }

開局就是一把問號，帶着問題進行學習。請問 main 調用 GetUserInfo 後返回的 &User{...}。這個變量是分配到棧上了呢，仍是分配到堆上了？

什麼是堆/棧

在這裏並不打算詳細介紹堆棧，僅簡單介紹本文所需的基礎知識。以下：

• 堆（Heap）：通常來說是人爲手動進行管理，手動申請、分配、釋放。通常所涉及的內存大小並不定，通常會存放較大的對象。另外其分配相對慢，涉及到的指令動做也相對多
• 棧（Stack）：由編譯器進行管理，自動申請、分配、釋放。通常不會太大，咱們常見的函數參數（不一樣平臺容許存放的數量不一樣），局部變量等等都會存放在棧上

今天咱們介紹的 Go 語言，它的堆棧分配是經過 Compiler 進行分析，GC 去管理的，而對其的分析選擇動做就是今天探討的重點

什麼是逃逸分析

在編譯程序優化理論中，逃逸分析是一種肯定指針動態範圍的方法，簡單來講就是分析在程序的哪些地方能夠訪問到該指針

通俗地講，逃逸分析就是肯定一個變量要放堆上仍是棧上，規則以下：

1. 是否有在其餘地方（非局部）被引用。只要有可能被引用了，那麼它必定分配到堆上。不然分配到棧上
2. 即便沒有被外部引用，但對象過大，沒法存放在棧區上。依然有可能分配到堆上

對此你能夠理解爲，逃逸分析是編譯器用於決定變量分配到堆上仍是棧上的一種行爲

在什麼階段確立逃逸

在編譯階段確立逃逸，注意並非在運行時

爲何須要逃逸

這個問題咱們能夠反過來想，若是變量都分配到堆上了會出現什麼事情？例如：

• 垃圾回收（GC）的壓力不斷增大
• 申請、分配、回收內存的系統開銷增大（相對於棧）
• 動態分配產生必定量的內存碎片

其實總的來講，就是頻繁申請、分配堆內存是有必定 「代價」 的。會影響應用程序運行的效率，間接影響到總體系統。所以 「按需分配」 最大限度的靈活利用資源，纔是正確的治理之道。這就是爲何須要逃逸分析的緣由，你以爲呢？

怎麼肯定是否逃逸

第一，經過編譯器命令，就能夠看到詳細的逃逸分析過程。而指令集 -gcflags 用於將標識參數傳遞給 Go 編譯器，涉及以下：

• -m 會打印出逃逸分析的優化策略，實際上最多總共能夠用 4 個 -m，可是信息量較大，通常用 1 個就能夠了

• -l 會禁用函數內聯，在這裏禁用掉 inline 能更好的觀察逃逸狀況，減小干擾

$ go build -gcflags '-m -l' main.go

第二，經過反編譯命令查看

$ go tool compile -S main.go

注：能夠經過 go tool compile -help 查看全部容許傳遞給編譯器的標識參數

逃逸案例

案例一：指針

第一個案例是一開始拋出的問題，如今你再看看，想一想，以下：

type User struct { ID int64 Name string Avatar string } func GetUserInfo() *User { return &User{ID: 13746731, Name: "EDDYCJY", Avatar: "https://avatars0.githubusercontent.com/u/13746731"} } func main() { _ = GetUserInfo() }

執行命令觀察一下，以下：

$ go build -gcflags '-m -l' main.go # command-line-arguments ./main.go:10:54: &User literal escapes to heap

經過查看分析結果，可得知 &User 逃到了堆裏，也就是分配到堆上了。這是否是有問題啊...再看看彙編代碼肯定一下，以下：

$ go tool compile -S main.go "".GetUserInfo STEXT size=190 args=0x8 locals=0x18 0x0000 00000 (main.go:9) TEXT "".GetUserInfo(SB), $24-8 ... 0x0028 00040 (main.go:10) MOVQ AX, (SP) 0x002c 00044 (main.go:10) CALL runtime.newobject(SB) 0x0031 00049 (main.go:10) PCDATA $2, $1 0x0031 00049 (main.go:10) MOVQ 8(SP), AX 0x0036 00054 (main.go:10) MOVQ $13746731, (AX) 0x003d 00061 (main.go:10) MOVQ $7, 16(AX) 0x0045 00069 (main.go:10) PCDATA $2, $-2 0x0045 00069 (main.go:10) PCDATA $0, $-2 0x0045 00069 (main.go:10) CMPL runtime.writeBarrier(SB), $0 0x004c 00076 (main.go:10) JNE 156 0x004e 00078 (main.go:10) LEAQ go.string."EDDYCJY"(SB), CX ...

咱們將目光集中到 CALL 指令，發現其執行了 runtime.newobject 方法，也就是確實是分配到了堆上。這是爲何呢？

分析結果

這是由於 GetUserInfo() 返回的是指針對象，引用被返回到了方法以外了。所以編譯器會把該對象分配到堆上，而不是棧上。不然方法結束以後，局部變量就被回收了，豈不是翻車。因此最終分配到堆上是理所固然的

再想一想

那你可能會想，那就是全部指針對象，都應該在堆上？並不。以下：

func main() { str := new(string) *str = "EDDYCJY" }

你想一想這個對象會分配到哪裏？以下：

$ go build -gcflags '-m -l' main.go # command-line-arguments ./main.go:4:12: main new(string) does not escape

顯然，該對象分配到棧上了。很核心的一點就是它有沒有被做用域以外所引用，而這裏做用域仍然保留在 main 中，所以它沒有發生逃逸

案例二：未肯定類型

func main() { str := new(string) *str = "EDDYCJY" fmt.Println(str) }

執行命令觀察一下，以下：

$ go build -gcflags '-m -l' main.go # command-line-arguments ./main.go:9:13: str escapes to heap ./main.go:6:12: new(string) escapes to heap ./main.go:9:13: main ... argument does not escape

經過查看分析結果，可得知 str 變量逃到了堆上，也就是該對象在堆上分配。但上個案例時它還在棧上，咱們也就 fmt 輸出了它而已。這...到底發生了什麼事？

分析結果

相對案例一，案例二隻加了一行代碼 fmt.Println(str)，問題確定出在它身上。其原型：

func Println(a ...interface{}) (n int, err error)

經過對其分析，可得知當形參爲 interface 類型時，在編譯階段編譯器沒法肯定其具體的類型。所以會產生逃逸，最終分配到堆上

若是你有興趣追源碼的話，能夠看下內部的 reflect.TypeOf(arg).Kind() 語句，其會形成堆逃逸，而表象就是 interface 類型會致使該對象分配到堆上

案例3、泄露參數

type User struct { ID int64 Name string Avatar string } func GetUserInfo(u *User) *User { return u } func main() { _ = GetUserInfo(&User{ID: 13746731, Name: "EDDYCJY", Avatar: "https://avatars0.githubusercontent.com/u/13746731"}) }

執行命令觀察一下，以下：

$ go build -gcflags '-m -l' main.go # command-line-arguments ./main.go:9:18: leaking param: u to result ~r1 level=0 ./main.go:14:63: main &User literal does not escape

咱們注意到 leaking param 的表述，它說明了變量 u 是一個泄露參數。結合代碼可得知其傳給 GetUserInfo 方法後，沒有作任何引用之類的涉及變量的動做，直接就把這個變量返回出去了。所以這個變量實際上並無逃逸，它的做用域還在 main() 之中，因此分配在棧上

再想一想

那你再想一想怎麼樣才能讓它分配到堆上？結合案例一，觸類旁通。修改以下：

type User struct { ID int64 Name string Avatar string } func GetUserInfo(u User) *User { return &u } func main() { _ = GetUserInfo(User{ID: 13746731, Name: "EDDYCJY", Avatar: "https://avatars0.githubusercontent.com/u/13746731"}) }

執行命令觀察一下，以下：

$ go build -gcflags '-m -l' main.go # command-line-arguments ./main.go:10:9: &u escapes to heap ./main.go:9:18: moved to heap: u

只要一小改，它就考慮會被外部所引用，所以妥妥的分配到堆上了

總結

• 靜態分配到棧上，性能必定比動態分配到堆上好
• 底層分配到堆，仍是棧。實際上對你來講是透明的，不須要過分關心
• 每一個 Go 版本的逃逸分析都會有所不一樣（會改變，會優化）
• 直接經過 go build -gcflags '-m -l' 就能夠看到逃逸分析的過程和結果
• 處處都用指針傳遞並不必定是最好的，要用對

參考

• Golang escape analysis
• FAQ
• 逃逸分析