https://mp.weixin.qq.com/s/3Nsm_CFE7r60f6vFyyWkuw
前段時間在我的 Go 讀者群里，有小伙伴們在糾結切片（slice）的問題，我寫了這篇《Go 切片這道題，吵了一個下午！》，引起了一撥各種討論，還是比較欣慰的。
這不，有小伙伴給我提出了新的題材：
來自讀者微信提問
提出的是 Go 中很容易踩坑的切片內存泄露問題。作為寵粉的煎魚肯定不會放過，爭取讓大家都避開這個 “坑”。
今天這篇文章，就由煎魚帶大家來了解這個問題：Go 切片可能可以怎么泄露法？
切片泄露的可能
在業務代碼的編寫上，我們經常會接受來自外部的接口數據，再把他插入到對應的數據結構中去，再進行下一步的業務聚合、裁剪、封裝、處理。
像在 PHP 語言，常常會放到數組（array）中。在 Go 語言，會放到切片（slice）中。因此在 Go 的切片處理邏輯中，常常會涉及到如下類似的動作。
示例代碼如下：
var a []int
func f(b []int) []int {
a = b[:2]
return a
}
func main() {
...
}
仔細想想，這段程序有沒有問題，是否存在內存泄露的風險？
答案是：有的。有明確的切片內存泄露的可能性和風險。
切片底層結構
可能有些小伙伴會疑惑，怎么就有問題了，是哪里有問題？
這里就得復習一下切片的底層基本數據結構了，切片在運行時的表現是 SliceHeader 結構體，定義如下：
type SliceHeader struct {
Data uintptr
Len int
Cap int
}
- Data：指向具體的底層數組。
- Len：代表切片的長度。
- Cap：代表切片的容量。
要點是：切片真正存儲數據的地方，是一個數組。切片的 Data 屬性中存儲的是指向所引用的數組指針地址。
背后的原因
在上述案例中，我們有一個包全局變量 a，共有 2 個切片 a 和 b，截取了 b 的一部分賦值給了 a，兩者存在着關聯。
從程序的直面來看，截取了 b 的一部分賦值給了 a，結構似乎是如下圖：
但我們進一步打開程序底層來看，他應該是如下圖所示
切片 a 和 b 都共享着同一個底層數組（共享內存塊），sliceB 包含全部所引用的字符。sliceA 只包含了 [:2]，也就是 0 和 1 兩個索引位的字符。
那他們泄露在哪里了？
泄露的點
泄露的點，就在於雖然切片 b 已經在函數內結束了他的使命了，不再使用了。但切片 a 還在使用，切片 a 和 切片 b 引用的是同一塊底層數組（共享內存塊）。
關鍵點：切片 a 引用了底層數組中的一段。
雖然切片 a 只有底層數組中 0 和 1 兩個索引位正在被使用，其余未使用的底層數組空間毫無作用。但由於正在被引用，他們也不會被 GC，因此造成了泄露。
解決辦法
解決的辦法，就是利用切片的特性。當切片的容量空間不足時，會重新申請一個新的底層數組來存儲，讓兩者徹底分手。
示例代碼如下：
var a []int
var c []int // 第三者
func f(b []int) []int {
a = b[:2]
// 新的切片 append 導致切片擴容
c = append(c, b[:2]...)
fmt.Printf("a: %p\nc: %p\nb: %p\n", &a[0], &c[0], &b[0])
return a
}
輸出結果：
a: 0xc000102060
c: 0xc000124010
b: 0xc000102060
這段程序，新增了一個變量 c，他容量為 0。此時將期望的數據，追加過去。自然而然他就會遇到容量空間不足的情況，也就能實現申請新底層數據。
我們再將原本的切片置為 nil，就能成功實現兩者分手的目標了。
總結
在今天這篇文章中，我們介紹了 Go 切片的一種常見的內存泄露方式。雖然我們在日常使用的時候可能沒關注到。
主要原因還是由於切片的大多數使用場景，體量都比較小。又或是不知不覺就自己擴容了，就變成暫時性泄露了。
這依然是存在風險的，在編寫 Go 代碼時需要謹慎。畢竟這可是 Go 語言官方自己都踩過坑的 “坑”。