Go map 竟然也會(huì)發(fā)生內(nèi)存泄漏？

Go 程序運(yùn)行時(shí)，有些場(chǎng)景下會(huì)導(dǎo)致進(jìn)程進(jìn)入某個(gè)“高點(diǎn)”，然后就再也下不來(lái)了。

比如，多年前曹大寫過(guò)的一篇文章^[1]講過(guò)，在做活動(dòng)時(shí)線上涌入的大流量把 goroutine 數(shù)抬升了不少，流量恢復(fù)之后 goroutine 數(shù)也沒(méi)降下來(lái)，導(dǎo)致 GC 的壓力升高，總體的 CPU 消耗也較平時(shí)上升了 2 個(gè)點(diǎn)左右。

有一個(gè) issue^[2] 討論為什么 allgs（runtime 中存儲(chǔ)所有 goroutine 的一個(gè)全局 slice） 不收縮，一個(gè)好處是：goroutine 復(fù)用，讓 goroutine 的創(chuàng)建更加得便利，而這也正是 Go 語(yǔ)言的一大優(yōu)勢(shì)。

最近在看《100 mistakes》，書里專門有一節(jié)講 map 的內(nèi)存泄漏。其實(shí)這也是另一個(gè)在經(jīng)歷大流量后，無(wú)法“恢復(fù)”的例子：map 占用的內(nèi)存“只增不減”。

之前寫過(guò)的一篇《深度解密 Go 語(yǔ)言之 map》^[3]里講到過(guò) map 的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，并且分析過(guò)創(chuàng)建、遍歷、刪除的過(guò)程。

在 Go runtime 層，map 是一個(gè)指向 hmap 結(jié)構(gòu)體的指針，hmap 里有一個(gè)字段 B，它決定了 map 能存放的元素個(gè)數(shù)。

hamp 結(jié)構(gòu)體代碼如下：

type hmap struct {
 count     int
 flags     uint8
 B         uint8
 
 // ...
}

若我們想初始化一個(gè)長(zhǎng)度為 100w 元素的 map，B 是多少呢？

用 B 可以計(jì)算 map 的元素個(gè)數(shù)：loadfactor * 2^B，loadfactor 目前是 6.5，當(dāng) B=17 時(shí)，可放 851,968 個(gè)元素；當(dāng) B=18，可放 1,703,936 個(gè)元素。因此當(dāng)我們將 map 的長(zhǎng)度初始化為 100w 時(shí)，B 的值應(yīng)是 18。

loadfactor 是裝載因子，用來(lái)衡量平均一個(gè) bucket 里有多少個(gè) key。

如何查看占用的內(nèi)存數(shù)量呢？用 runtime.MemStats：

package main

import (
 "fmt"
 "runtime"
)

const N = 128

func 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 會(huì)被回收掉。

當(dāng) N = 128 時(shí)，運(yùn)行程序：

$ go run main2.go
0 MB
461 MB
293 MB

可以看到，當(dāng)刪除了所有 kv 后，內(nèi)存占用依然有 293 MB，這實(shí)際上是創(chuàng)建長(zhǎng)度為 100w 的 map 所消耗的內(nèi)存大小。當(dāng)我們創(chuàng)建一個(gè)初始長(zhǎng)度為 100w 的 map：

package main

import (
 "fmt"
 "runtime"
)

const N = 128

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, n)
 printAlloc()

 runtime.KeepAlive(m)
}

運(yùn)行程序，得到 100w 長(zhǎng)度的 map 的消耗的內(nèi)存為：

$ go run main3.go
293 MB

這時(shí)有一個(gè)疑惑，為什么在向 map 寫入了 100w 個(gè) kv 之后，占用內(nèi)存變成了 461MB？

我們知道，當(dāng) val 大小 <= 128B 時(shí)，val 其實(shí)是直接放在 bucket 里的，按理說(shuō)，寫入 kv 與否，這些 bucket 占用的內(nèi)存都在那里。換句話說(shuō)，寫入 kv 之后，占用的內(nèi)存應(yīng)該還是 293MB，實(shí)際上卻是 461MB。

這里的原因其實(shí)是在寫入 100w kv 期間 map 發(fā)生了擴(kuò)容，buckets 進(jìn)行了搬遷。我們可以用 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)
}

運(yùn)行程序，B 值從 1 一直變到 18。搬遷的過(guò)程可以參考前面提到的那篇 map 文章，這里不再贅述。

而如果我們初始化的時(shí)候直接將 map 的長(zhǎng)度指定為 100w，那內(nèi)存變化情況為：

293 MB
293 MB
293 MB

當(dāng) val 小于 128B 時(shí)，初始化 map 后內(nèi)存占用量一直不變。原因是 put 操作只是在 bucket 里原地寫入 val，而 delete 操作則是將 val 清零，bucket 本身還在。因此，內(nèi)存占用大小不變。

而當(dāng) val 大小超過(guò) 128B 后，bucket 不會(huì)直接放 val，轉(zhuǎn)而變成一個(gè)指針。我們將 N 設(shè)為 129，運(yùn)行程序：

0 MB
197 MB
38 MB

雖然 map 的 bucket 占用內(nèi)存量依然存在，但 val 改成指針存儲(chǔ)后內(nèi)存占用量大大降低。且 val 被刪掉后，內(nèi)存占用量確實(shí)降低了。

總之，map 的 buckets 數(shù)只會(huì)增，不會(huì)降。所以在流量沖擊后，map 的 buckets 數(shù)增長(zhǎng)到一定值，之后即使把元素都刪了也無(wú)濟(jì)于事。內(nèi)存占用還是在，因?yàn)?buckets 占用的內(nèi)存不會(huì)少。

對(duì)于 map 內(nèi)存泄漏的解法：

• 重啟；
• 將 val 類型改成指針；
• 定期地將 map 里的元素全量拷貝到另一個(gè) map 里。

好在一般有大流量沖擊的互聯(lián)網(wǎng)業(yè)務(wù)大都是 toC 場(chǎng)景，上線頻率非常高。有的公司能一天上線好幾次，在問(wèn)題暴露之前就已經(jīng)重啟恢復(fù)了，問(wèn)題不大。

參考資料