1. 首頁 > 生活百科 > >

Go map 竟然也會發生內存泄露？

生活百科

Go 程序運行時，有些場景下會導致進程進入某個“高點”，然后就再也下不來了 。
比如，多年前曹大寫過的一篇文章講過，在做活動時線上涌入的大流量把 goroutine 數抬升了不少，流量恢復之后 goroutine 數也沒降下來，導致 GC 的壓力升高，總體的 CPU 消耗也較平時上升了 2 個點左右 。
有一個 issue 討論為什么 allgs（runtime 中存儲所有 goroutine 的一個全局 slice） 不收縮，一個好處是：goroutine 復用 ， 讓 goroutine 的創建更加得便利 ， 而這也正是 Go 語言的一大優勢 。
最近在看《100 mistakes》，書里專門有一節講 map 的內存泄露 。其實這也是另一個在經歷大流量后，無法“恢復”的例子：map 占用的內存“只增不減” 。
之前寫過的一篇《深度解密 Go 語言之 map》里講到過 map 的內部數據結構，并且分析過創建、遍歷、刪除的過程 。
在 Go runtime 層，map 是一個指向 hmap 結構體的指針，hmap 里有一個字段 B ， 它決定了 map 能存放的元素個數 。
hamp 結構體代碼如下：
type hmap struct { countint flagsuint8 Buint8 // ...}若我們想初始化一個長度為 100w 元素的 map ， B 是多少呢？
用 B 可以計算 map 的元素個數：loadfactor * 2^B，loadfactor 目前是 6.5，當 B=17 時 ， 可放 851,968 個元素；當 B=18，可放 1,703,936 個元素 。因此當我們將 map 的長度初始化為 100w 時，B 的值應是 18 。

loadfactor 是裝載因子，用來衡量平均一個 bucket 里有多少個 key 。
如何查看占用的內存數量呢？用 runtime.MemStats：
package mainimport ( "fmt" "runtime")const N = 128func randBytes() [N]byte { return [N]byte{}}func printAlloc() { var m runtime.MemStats runtime.ReadMemStats(&m) fmt.Printf("%d MB\n", m.Alloc/1024/1024)}func main() { n := 1_000_000 m := make(map[int][N]byte, 0) printAlloc() for i := 0; i < n; i++ {m[i] = randBytes() } printAlloc() for i := 0; i < n; i++ {delete(m, i) } runtime.GC() printAlloc() runtime.KeepAlive(m)}如果不加最后的 KeepAlive，m 會被回收掉 。
當 N = 128 時 ， 運行程序：
$ go run main2.go0 MB461 MB293 MB可以看到，當刪除了所有 kv 后，內存占用依然有 293 MB，這實際上是創建長度為 100w 的 map 所消耗的內存大小 。當我們創建一個初始長度為 100w 的 map：
package mainimport ( "fmt" "runtime")const N = 128func printAlloc() { var m runtime.MemStats runtime.ReadMemStats(&m) fmt.Printf("%d MB\n", m.Alloc/1024/1024)}func main() { n := 1_000_000 m := make(map[int][N]byte, n) printAlloc() runtime.KeepAlive(m)}運行程序，得到 100w 長度的 map 的消耗的內存為：
$ go run main3.go293 MB這時有一個疑惑 ， 為什么在向 map 寫入了 100w 個 kv 之后，占用內存變成了 461MB？
我們知道，當 val 大小 <= 128B 時 ， val 其實是直接放在 bucket 里的，按理說，寫入 kv 與否，這些 bucket 占用的內存都在那里 。換句話說，寫入 kv 之后 ， 占用的內存應該還是 293MB，實際上卻是 461MB 。
這里的原因其實是在寫入 100w kv 期間 map 發生了擴容 ， buckets 進行了搬遷 。我們可以用 hack 的方式打印出 B 值：
func main() { //... var B uint8 for i := 0; i < n; i++ {curB := *(*uint8)(unsafe.Pointer(uintptr(unsafe.Pointer(*(**int)(unsafe.Pointer(&m)))) + 9))if B != curB {fmt.Println(curB)B = curB}m[i] = randBytes() } //... runtime.KeepAlive(m)}【Go map 竟然也會發生內存泄露？】運行程序，B 值從 1 一直變到 18 。搬遷的過程可以參考前面提到的那篇 map 文章，這里不再贅述 。
而如果我們初始化的時候直接將 map 的長度指定為 100w ， 那內存變化情況為：
293 MB293 MB293 MB當 val 小于 128B 時，初始化 map 后內存占用量一直不變 。原因是 put 操作只是在 bucket 里原地寫入 val ， 而 delete 操作則是將 val 清零，bucket 本身還在 。因此，內存占用大小不變 。
而當 val 大小超過 128B 后，bucket 不會直接放 val，轉而變成一個指針 。我們將 N 設為 129，運行程序：
0 MB197 MB38 MB雖然 map 的 bucket 占用內存量依然存在，但 val 改成指針存儲后內存占用量大大降低 。且 val 被刪掉后，內存占用量確實降低了 。
總之，map 的 buckets 數只會增，不會降 。所以在流量沖擊后，map 的 buckets 數增長到一定值，之后即使把元素都刪了也無濟于事 。內存占用還是在，因為 buckets 占用的內存不會少 。
對于 map 內存泄露的解法：

推薦閱讀