1. 引言
關於閉包的說明，曾在很多篇幅中都有過一些說明，包括Go基礎--函式2, go 函式進階，異常與錯誤 都有所提到， 但是會發現，好像原理（理論）都懂，但是就是不知道如何使用，或者在看到一些原始碼時，依然一頭霧水。 剛好今天看到了一篇優質的部落格，並結合以前幾篇關於類似閉包的介紹，再次對 閉包進行一次分析。
2. 什麼是閉包？
函式內部包含另一個函式: 且返回的是一個函式型別
2.1. 一個簡單的例子
【示例1】
package main
import (
"fmt"
)
// 累加器
func AddWrapper() func(int) int {
var n int = 10
return func(x int) int {
n = n + x
return n
}
}
func main() {
f := AddWrapper()
fmt.Println(f(1)) // 11
fmt.Println(f(2)) // 13
fmt.Println(f(3)) // 16
}
2.2理解閉包
- 閉包本身是一個函式, 且返回的一個函式
func (int) int - 返回的是一個匿名函式,但是這個匿名函式 引用到了函式(匿名)函式外的變數(上面示例是 n),因此這個匿名函式就和n 形成了一個整體, 構成閉包.
- 相比較類可以這麼理解: 閉包是類(class),函式是類裡面的某個方法, n是欄位(屬性),函式和他使用到的n構成閉包
當反覆呼叫AddWrapper 函式時, n只被初始化一次,因此每呼叫一次就進行累計
例如上面的程式碼中，AddWrapper函式返回了一個匿名函式，而該匿名函式中引用了AddWrapper函式中的區域性變數n ，那這個函式就是一個閉包。
呼叫這個函式，發現每一次呼叫，n 的值都會保留在 閉包函式中以待使用。
閉包中引用的外部區域性變數並不會隨著 AddWrapper 函式的返回而被從棧上銷燬。
3. 複雜的閉包場景
寫一個閉包是比較容易的事，但單單會寫簡單的閉包函式，還遠遠不夠，如果不搞清楚閉包真正的原理，那很容易在一些複雜的閉包場景中對函式的執行邏輯進行誤判。
別的不說，就拿下來這個例子來說吧？
你覺得它會列印什麼呢？
是 6 還是 11 呢？
【示例2】
import "fmt"
func func1() (i int) {
i = 10
defer func() {
i += 1
}()
// 相當於兩條語句
// i = 5
// return i
return 5
}
func main() {
closure := func1()
fmt.Println(closure)
}
先不執行，先來了解下閉包的底層原理
4.閉包的底層原理？
以最上面的例子進行分析
package main
import (
"fmt"
)
// 累加器
func AddWrapper() func(int) int {
var n int = 10
return func(x int) int {
n = n + x
return n
}
}
func main() {
f := AddWrapper()
fmt.Println(f(1)) // 11
fmt.Println(f(2)) // 13
fmt.Println(f(3)) // 16
}
先對它進行逃逸分析，很容易發現 n 作為 AddWrapper 函式區域性變數，並不是分配在棧上，而是分配在堆上的。
D:\gopath\src\Go_base\daily_test\閉包> go build -gcflags="-m -m -l" demo.go
# command-line-arguments
.\demo.go:11:7: AddWrapper.func1 capturing by ref: n (addr=true assign=true width=8)
.\demo.go:10:9: func literal escapes to heap:
.\demo.go:10:9: flow: ~r0 = &{storage for func literal}:
.\demo.go:10:9: from func literal (spill) at .\demo.go:10:9
.\demo.go:10:9: from return func literal (return) at .\demo.go:10:2
.\demo.go:9:6: n escapes to heap:
.\demo.go:9:6: flow: {storage for func literal} = &n:
.\demo.go:9:6: from func literal (captured by a closure) at .\demo.go:10:9
.\demo.go:9:6: from n (reference) at .\demo.go:11:7
.\demo.go:9:6: moved to heap: n
.\demo.go:10:9: func literal escapes to heap
.\demo.go:21:15: f(3) escapes to heap:
.\demo.go:21:15: flow: {storage for ... argument} = &{storage for f(3)}:
.\demo.go:21:15: from f(3) (spill) at .\demo.go:21:15
.\demo.go:21:15: from ... argument (slice-literal-element) at .\demo.go:21:13
.\demo.go:21:15: flow: {heap} = {storage for ... argument}:
.\demo.go:21:15: from ... argument (spill) at .\demo.go:21:13
.\demo.go:21:15: from fmt.Println(... argument...) (call parameter) at .\demo.go:21:13
.\demo.go:20:15: f(2) escapes to heap:
.\demo.go:20:15: flow: {storage for ... argument} = &{storage for f(2)}:
.\demo.go:20:15: from f(2) (spill) at .\demo.go:20:15
.\demo.go:20:15: from ... argument (slice-literal-element) at .\demo.go:20:13
.\demo.go:20:15: flow: {heap} = {storage for ... argument}:
.\demo.go:20:15: from ... argument (spill) at .\demo.go:20:13
.\demo.go:20:15: from fmt.Println(... argument...) (call parameter) at .\demo.go:20:13
.\demo.go:19:15: f(1) escapes to heap:
.\demo.go:19:15: flow: {storage for ... argument} = &{storage for f(1)}:
.\demo.go:19:15: from f(1) (spill) at .\demo.go:19:15
.\demo.go:19:15: from ... argument (slice-literal-element) at .\demo.go:19:13
.\demo.go:19:15: flow: {heap} = {storage for ... argument}:
.\demo.go:19:15: from ... argument (spill) at .\demo.go:19:13
.\demo.go:19:15: from fmt.Println(... argument...) (call parameter) at .\demo.go:19:13
.\demo.go:19:13: ... argument does not escape
.\demo.go:19:15: f(1) escapes to heap
.\demo.go:20:13: ... argument does not escape
.\demo.go:20:15: f(2) escapes to heap
.\demo.go:21:13: ... argument does not escape
.\demo.go:21:15: f(3) escapes to heap
這就解決了第一個疑惑：為什麼 AddWrapper 函式返回後， n 不會隨之銷燬？
可另一個問題，又浮現出來了，就算它不會銷燬，那閉包函式若是儲存的若是 sum 拷貝後的值，那每次呼叫閉包函式，裡面的 n 應該都是一樣的，呼叫3次應該是11，12，13，而不是可以累加記錄。
因此，可以大膽猜測，閉包函式的結構體裡儲存的是 n 的指標。
為了驗證這一猜想，只能上彙編了。
通過執行下面的命令，可以輸出對應的彙編程式碼。
D:\gopath\src\Go_base\daily_test\閉包>go build -gcflags="-S" demo.go
# command-line-arguments
"".AddWrapper STEXT size=159 args=0x8 locals=0x20 funcid=0x0
0x0000 00000 (D:\gopath\src\Go_base\daily_test\閉包\demo.go:8) TEXT "".AddWrapper(SB), ABIInternal, $32-8
0x0000 00000 (D:\gopath\src\Go_base\daily_test\閉包\demo.go:8) MOVQ TLS, CX
0x0009 00009 (D:\gopath\src\Go_base\daily_test\閉包\demo.go:8) PCDATA $0, $-2
0x0045 00069 (D:\gopath\src\Go_base\daily_test\閉包\demo.go:10) LEAQ type.noalg.struct { F uintptr; "".n *int }(SB), CX
輸出的很多，提取出上面最關鍵的一行程式碼，它定義了閉包函式的結構體。
其中 F 是函式的指標，但這不是重點，重點是 n 儲存的確實是指標.
type.noalg.struct { F uintptr; "".n *int }
5. 迷題揭曉
有了對閉包原理的認識，那對於第3節給出的這道題，很明顯可以知道輸出的內容是6。
import "fmt"
func func1() (i int) {
i = 10
defer func() {
i += 1
}()
return 5
}
func main() {
closure := func1()
fmt.Println(closure)
}
-
首先，由於
i在函式定義的返回值上宣告，因此根據 go 的caller-save模式， i 變數會儲存在 main 函式的棧空間。- Callee-saved register（又稱非易失性暫存器AKA non-volatile registers, or call-preserved）用於儲存應在每次呼叫中保留的長壽命值。
- 呼叫者儲存”（ caller saving ）方法：如果採用呼叫者儲存策略，那麼在一個呼叫者呼叫別的過程時，必須儲存呼叫者所要儲存的暫存器，以備呼叫結束返回後，能夠再次訪問呼叫者。
-
然後，func1 的 return 重新把 5 賦值給了 i ，此時 i = 5
-
由於閉包函式儲存了這個變數 i 的指標。
-
因此最後，在 defer 中對 i 進行自增，是直接更新到 i 的指標上，此時 i = 5+1，所以最終列印出來的結果是 6
6. 可能的坑
上面那題聽懂了的話，再來看看下面這道題。
func1 的返回值我們不寫變數名 i 了，然後原先返回具體字面量，現在改成變數 i ，就是這兩小小小的改動，會導致執行結果大大不同。
【示例3】
import "fmt"
func func1() (int) {
i := 10
defer func() {
// 函式內部的作用域並不會作用到外部
i += 1
}()
return i
}
func main() {
closure := func1()
fmt.Println(closure)
}
如果在返回值裡寫了變數名，那麼該變數會儲存 main 的棧空間裡，而如果你不寫，那 i 只能儲存在 func1 的棧空間裡，與此同時，return 的值，不會作用於原變數 i 上，而是會儲存在該函式在另一塊棧記憶體裡。
因此你在 defer 中對原 i 進行自增，並不會作用到 func1 的返回值上。
所以列印的結果，只能是 10。
7. 總結
示例1中的 n是儲存在堆記憶體中的，而後面幾個示例都是儲存在棧記憶體裡。
這是為什麼呢？
仔細對比，不難發現，示例1返回的是閉包函式，閉包函式在 AddWrapper 返回後還要在其他地方繼續使用，在這種情況下，為了保證閉包函式的正常執行，無論閉包函式在哪裡，i 都不能回收，所以 Go 編譯器會智慧地將其分配在堆上。
而後面的其他示例，都只是涉及了閉包的特性，並不是直接把閉包函式返回，因此完全可以將其分配在棧上，非常的合理。
閉包的優勢: 類似於物件導向程式設計中, 引用的變數相當於 類中的一個屬性, 返回的匿名函式相當於修改了屬性值, 但是在每次呼叫時,不需要重複傳入引用的變數.