Go 程序運行時，有些場景下會導(dǎo)致進(jìn)程進(jìn)入某個“高點”，然后就再也下不來了。

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

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

(相關(guān)資料圖)

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

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

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

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

typehmapstruct{countintflagsuint8Buint8//...}

若我們想初始化一個長度為 100w 元素的 map，B 是多少呢？

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

loadfactor 是裝載因子，用來衡量平均一個 bucket 里有多少個 key。

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

packagemainimport("fmt""runtime")constN=128funcrandBytes()[N]byte{return[N]byte{}}funcprintAlloc(){varmruntime.MemStatsruntime.ReadMemStats(&m)fmt.Printf("%dMB\n",m.Alloc/1024/1024)}funcmain(){n:=1_000_000m:=make(map[int][N]byte,0)printAlloc()fori:=0;i
如果不加最后的 KeepAlive，m 會被回收掉。
當(dāng) N = 128 時，運行程序：
$gorunmain2.go0MB461MB293MB
可以看到，當(dāng)刪除了所有 kv 后，內(nèi)存占用依然有 293 MB，這實際上是創(chuàng)建長度為 100w 的 map 所消耗的內(nèi)存大小。當(dāng)我們創(chuàng)建一個初始長度為 100w 的 map：
packagemainimport("fmt""runtime")constN=128funcprintAlloc(){varmruntime.MemStatsruntime.ReadMemStats(&m)fmt.Printf("%dMB\n",m.Alloc/1024/1024)}funcmain(){n:=1_000_000m:=make(map[int][N]byte,n)printAlloc()runtime.KeepAlive(m)}
運行程序，得到 100w 長度的 map 的消耗的內(nèi)存為：
$gorunmain3.go293MB
這時有一個疑惑，為什么在向 map 寫入了 100w 個 kv 之后，占用內(nèi)存變成了 461MB？
我們知道，當(dāng) val 大小 <= 128B 時，val 其實是直接放在 bucket 里的，按理說，寫入 kv 與否，這些 bucket 占用的內(nèi)存都在那里。換句話說，寫入 kv 之后，占用的內(nèi)存應(yīng)該還是 293MB，實際上卻是 461MB。
這里的原因其實是在寫入 100w kv 期間 map 發(fā)生了擴(kuò)容，buckets 進(jìn)行了搬遷。我們可以用 hack 的方式打印出 B 值：
funcmain(){//...varBuint8fori:=0;i
運行程序，B 值從 1 一直變到 18。搬遷的過程可以參考前面提到的那篇 map 文章，這里不再贅述。
而如果我們初始化的時候直接將 map 的長度指定為 100w，那內(nèi)存變化情況為：
293MB293MB293MB
當(dāng) val 小于 128B 時，初始化 map 后內(nèi)存占用量一直不變。原因是 put 操作只是在 bucket 里原地寫入 val，而 delete 操作則是將 val 清零，bucket 本身還在。因此，內(nèi)存占用大小不變。
而當(dāng) val 大小超過 128B 后，bucket 不會直接放 val，轉(zhuǎn)而變成一個指針。我們將 N 設(shè)為 129，運行程序：
0MB197MB38MB
雖然 map 的 bucket 占用內(nèi)存量依然存在，但 val 改成指針存儲后內(nèi)存占用量大大降低。且 val 被刪掉后，內(nèi)存占用量確實降低了。
總之，map 的 buckets 數(shù)只會增，不會降。所以在流量沖擊后，map 的 buckets 數(shù)增長到一定值，之后即使把元素都刪了也無濟(jì)于事。內(nèi)存占用還是在，因為 buckets 占用的內(nèi)存不會少。
對于 map 內(nèi)存泄漏的解法：
重啟；將 val 類型改成指針；定期地將 map 里的元素全量拷貝到另一個 map 里。
好在一般有大流量沖擊的互聯(lián)網(wǎng)業(yè)務(wù)大都是 toC 場景，上線頻率非常高。有的公司能一天上線好幾次，在問題暴露之前就已經(jīng)重啟恢復(fù)了，問題不大。
參考資料[1]
文章: https://xargin.com/cpu-idle-cannot-recover-after-peak-load/
[2]
issue: https://github.com/golang/go/issues/34457
[3]
《深度解密 Go 語言之 map》: https://qcrao.com/post/dive-into-go-map/
 

關(guān)鍵詞：         
       運行程序 
              
       內(nèi)存泄漏 
              
       元素個數(shù)