前序（Prelude）
本系列文章總共四篇，主要幫助你們理解 Go 語言中一些語法結構和其背後的設計原則，包括指針、棧、堆、逃逸分析和值/指針傳遞。這是第二篇，主要介紹堆和逃逸分析。編程
如下是本系列文章的索引：json
介紹（Introduction）
在四部分系列的第一部分，我用一個將值共享給 goroutine 棧的例子介紹了指針結構的基礎。而我沒有說的是值存在棧之上的狀況。爲了理解這個，你須要學習值存儲的另一個位置：堆。有這個基礎，就能夠開始學習逃逸分析。安全
逃逸分析是編譯器用來決定你的程序中值的位置的過程。特別地，編譯器執行靜態代碼分析，以肯定一個構造體的實例化值是否會逃逸到堆。在 Go 語言中，你沒有可用的關鍵字或者函數，可以直接讓編譯器作這個決定。只可以經過你寫代碼的方式來做出這個決定。markdown
堆（Heaps）
堆是內存的第二區域，除了棧以外，用來存儲值的地方。堆沒法像棧同樣能自清理，因此使用這部份內存會形成很大的開銷（相比於使用棧）。重要的是，開銷跟 GC（垃圾收集），即被牽扯進來保證這部分區域乾淨的程序，有很大的關係。當垃圾收集程序運行時，它會佔用你的可用 CPU 容量的 25%。更有甚者，它會形成微秒級的 「stop the world」 的延時。擁有 GC 的好處是你能夠再也不關注堆內存的管理，這部分很複雜，是歷史上容易出錯的地方。數據結構
在 Go 中，會將一部分值分配到堆上。這些分配給 GC 帶來了壓力，由於堆上沒有被指針索引的值都須要被刪除。越多須要被檢查和刪除的值，會給每次運行 GC 時帶來越多的工做。因此，分配算法不斷地工做，以平衡堆的大小和它運行的速度。編程語言
共享棧（Sharing Stacks）
在 Go 語言中，不容許 goroutine 中的指針指向另一個 goroutine 的棧。這是由於當棧增加或者收縮時，goroutine 中的棧內存會被一塊新的內存替換。若是運行時須要追蹤指針指向其餘的 goroutine 的棧，就會形成很是多須要管理的內存，以致於更新指向那些棧的指針將使 「stop the world」 問題更嚴重。
這裏有一個棧被替換好幾回的例子。看輸出的第 2 和第 6 行。你會看到 main 函數中的棧的字符串地址值改變了兩次。https://play.golang.org/p/pxn5u4EBSI
逃逸機制（Escape Mechanics）
任什麼時候候，一個值被分享到函數棧幀範圍以外，它都會在堆上被從新分配。這是逃逸分析算法發現這些狀況和管控這一層的工做。（內存的）完整性在於確保對任何值的訪問始終是準確、一致和高效的。
經過查看這個語言機制瞭解逃逸分析。https://play.golang.org/p/Y_VZxYteKO
清單 1
package main type user struct { name string email string } func main() { u1 := createUserV1() u2 := createUserV2() println("u1", &u1, "u2", &u2) } //go:noinline func createUserV1() user { u := user{ name: "Bill", email: "bill@ardanlabs.com", } println("V1", &u) return u } //go:noinline func createUserV2() *user { u := user{ name: "Bill", email: "bill@ardanlabs.com", } println("V2", &u) return &u }
我使用 go:noinline 指令，阻止在 main 函數中，編譯器使用內聯代碼替代函數調用。內聯（優化）會使函數調用消失，並使例子複雜化。我將在下一篇博文介紹內聯形成的反作用。
在表 1 中，你能夠看到建立 user 值，並返回給調用者的兩個不一樣的函數。在函數版本 1 中，返回值。
清單 2
16 func createUserV1() user {
17 u := user{
18 name: "Bill",
19 email: "bill@ardanlabs.com",
20 }
21
22 println("V1", &u)
23 return u
24 }
我說這個函數返回的是值是由於這個被函數建立的 user 值被拷貝並傳遞到調用棧上。這意味着調用函數接收到的是這個值的拷貝。
你能夠看下第 17 行到 20 行 user 值被構造的過程。而後在第 23 行，user 值的副本被傳遞到調用棧並返回給調用者。函數返回後，棧看起來以下所示。
圖 1
你能夠看到圖 1 中，當調用完 createUserV1 ，一個 user 值同時存在（兩個函數的）棧幀中。在函數版本 2 中，返回指針。
清單 3
27 func createUserV2() *user {
28 u := user{
29 name: "Bill",
30 email: "bill@ardanlabs.com",
31 }
32
33 println("V2", &u)
34 return &u
35 }
我說這個函數返回的是指針是由於這個被函數建立的 user 值經過調用棧被共享了。這意味着調用函數接收到一個值的地址拷貝。
你能夠看到在第 28 行到 31 行使用相同的字段值來構造 user 值，但在第 34 行返回時倒是不一樣的。不是將 user 值的副本傳遞到調用棧，而是將 user 值的地址傳遞到調用棧。基於此，你也許會認爲棧在調用以後是這個樣子。
圖 2
若是看到的圖 2 真的發生的話，你將遇到一個問題。指針指向了棧下的無效地址空間。當 main 函數調用下一個函數，指向的內存將從新映射並將被從新初始化。
這就是逃逸分析將開始保持完整性的地方。在這種狀況下，編譯器將檢查到，在 createUserV2 的（函數）棧中構造 user 值是不安全的，所以，替代地，會在堆中構造（相應的）值。這（個分析並處理的過程）將在第 28 行構造時當即發生。
可讀性（Readability）
在上一篇博文中，咱們知道一個函數只能直接訪問它的（函數棧）空間，或者經過（函數棧空間內的）指針，經過跳轉訪問（函數棧空間外的）外部內存。這意味着訪問逃逸到堆上的值也須要經過指針跳轉。
記住 createUserV2 的代碼的樣子：
清單 4
27 func createUserV2() *user {
28 u := user{
29 name: "Bill",
30 email: "bill@ardanlabs.com",
31 }
32
33 println("V2", &u)
34 return &u
35 }
語法隱藏了代碼中真正發生的事情。第 28 行聲明的變量 u 表明一個 user 類型的值。Go 代碼中的類型構造不會告訴你值在內存中的位置。因此直到第 34 行返回類型時，你才知道值須要逃逸（處理）。這意味着，雖然 u 表明類型 user 的一個值，但對該值的訪問必須經過指針進行。
你能夠在函數調用以後，看到堆棧就像（圖 3）這樣。
圖 3
在 createUserV2 函數棧中，變量 u 表明的值存在於堆中，而不是棧。這意味着用 u 訪問值時，使用指針訪問而不是直接訪問。你可能想，爲何不讓 u 成爲指針，畢竟訪問它表明的值須要使用指針？
清單 5
27 func createUserV2() *user {
28 u := &user{
29 name: "Bill",
30 email: "bill@ardanlabs.com",
31 }
32
33 println("V2", u)
34 return u
35 }
若是你這樣作，將使你的代碼缺少重要的可讀性。（讓咱們）離開整個函數一秒，只關注 return。
清單 6
34 return u 35 }
這個 return 告訴你什麼了呢？它說明了返回 u 值的副本給調用棧。然而，當你使用 & 操做符，return 又告訴你什麼了呢？
清單 7
34 return &u 35 }
多虧了 & 操做符，return 告訴你 u 被分享給調用者，所以，已經逃逸到堆中。記住，當你讀代碼的時候，指針是爲了共享，& 操做符對應單詞 "sharing"。這在提升可讀性的時候很是有用，這（也）是你不想失去的部分。
清單 8
01 var u *user 02 err := json.Unmarshal([]byte(r), &u) 03 return u, err
爲了讓其能夠工做，你必定要經過共享指針變量（的方式）給（函數） json.Unmarshal。json.Unmarshal 調用時會建立 user 值並將其地址賦值給指針變量。https://play.golang.org/p/koI8EjpeIx
代碼解釋：
01：建立一個類型爲 user，值爲空的指針。
02：跟函數 json.Unmarshal 函數共享指針。
03：返回 u 的副本給調用者。
這裏並非很好理解，user值被 json.Unmarshal 函數建立，並被共享給調用者。
如何在構造過程當中使用語法語義來改變可讀性？
清單 9
01 var u user 02 err := json.Unmarshal([]byte(r), &u) 03 return &u, err
代碼解釋：
01：建立一個類型爲 user，值爲空的變量。
02：跟函數 json.Unmarshal 函數共享 u。
03：跟調用者共享 u。
這裏很是好理解。第 02 行共享 user 值到調用棧中的 json.Unmarshal，在第 03 行 user 值共享給調用者。這個共享過程將會致使 user 值逃逸。
在構建一個值時，使用值語義，並利用 & 操做符的可讀性來明確值是如何被共享的。
編譯器報告（Compiler Reporting）
想查看編譯器（關於逃逸分析）的決定，你可讓編譯器提供一份報告。你只須要在調用 go build 的時候，打開 -gcflags 開關，並帶上 -m 選項。
實際上總共可使用 4 個 -m，（但）超過 2 個級別的信息就已經太多了。我將使用 2 個 -m 的級別。
清單 10
$ go build -gcflags "-m -m" ./main.go:16: cannot inline createUserV1: marked go:noinline ./main.go:27: cannot inline createUserV2: marked go:noinline ./main.go:8: cannot inline main: non-leaf function ./main.go:22: createUserV1 &u does not escape ./main.go:34: &u escapes to heap ./main.go:34: from ~r0 (return) at ./main.go:34 ./main.go:31: moved to heap: u ./main.go:33: createUserV2 &u does not escape ./main.go:12: main &u1 does not escape ./main.go:12: main &u2 does not escape
你能夠看到編譯器報告是否須要逃逸處理的決定。編譯器都說了什麼呢？請再看一下引用的 createUserV1 和 createUserV2 函數。
清單 13
16 func createUserV1() user {
17 u := user{
18 name: "Bill",
19 email: "bill@ardanlabs.com",
20 }
21
22 println("V1", &u)
23 return u
24 }
27 func createUserV2() *user {
28 u := user{
29 name: "Bill",
30 email: "bill@ardanlabs.com",
31 }
32
33 println("V2", &u)
34 return &u
35 }
從報告中的這一行開始。
清單 14
./main.go:22: createUserV1 &u does not escape
這是說在函數 createUserV1 調用 println 不會形成 user 值逃逸到堆。這是必須檢查的，由於它將會跟函數 println 共享（u）。
接下來看報告中的這幾行。
清單 15
./main.go:34: &u escapes to heap ./main.go:34: from ~r0 (return) at ./main.go:34 ./main.go:31: moved to heap: u ./main.go:33: createUserV2 &u does not escape
這幾行是說，類型爲 user，並在第 31 行被賦值的 u 的值，由於第 34 行的 return 逃逸。最後一行是說，跟以前同樣，在 33 行調用 println 不會形成 user 值逃逸。
閱讀這些報告可能讓人感到困惑，（編譯器）會根據所討論的變量的類型是基於值類型仍是指針類型而略有變化。
將 u 改成指針類型的 *user，而不是以前的命名類型 user。
清單 16
27 func createUserV2() *user {
28 u := &user{
29 name: "Bill",
30 email: "bill@ardanlabs.com",
31 }
32
33 println("V2", u)
34 return u
35 }
再次生成報告。
清單 17
./main.go:30: &user literal escapes to heap ./main.go:30: from u (assigned) at ./main.go:28 ./main.go:30: from ~r0 (return) at ./main.go:34
如今報告說在 28 行賦值的指針類型 *user，u 引用的 user 值，由於 34 行的 return 逃逸。
結論
值在構建時並不能決定它將存在於哪裏。只有當一個值被共享，編譯器才能決定如何處理這個值。當你在調用時，共享了棧上的一個值時，它就會逃逸。在下一篇中你將探索一個值逃逸的其餘緣由。
這些文章試圖引導你選擇給定類型的值或指針的指導原則。每種方式都有（對應的）好處和（額外的）開銷。保持在棧上的值，減小了 GC 的壓力。可是須要存儲，跟蹤和維護不一樣的副本。將值放在堆上的指針，會增長 GC 的壓力。然而，也有它的好處，只有一個值須要存儲，跟蹤和維護。（其實，）最關鍵的是如何保持正確地、一致地以及均衡（開銷）地使用。