今日報丨Go map 竟然也會發(fā)生內(nèi)存泄漏?
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)閱讀
-
世界熱推薦:今晚7:00直播丨下一個突破...
今晚19:00,Cocos視頻號直播馬上點擊【預(yù)約】啦↓↓↓在運營了三年... -
NFT周刊|Magic Eden宣布支持Polygon網(wǎng)...
Block-986在NFT這樣的市場,每周都會有相當(dāng)多項目起起伏伏。在過去... -
環(huán)球今亮點!頭條觀察 | DeFi的興衰與...
在比特幣得到機(jī)構(gòu)關(guān)注之后,許多財務(wù)專家預(yù)測世界將因為加密貨幣的... -
重新審視合作,體育Crypto的可靠關(guān)系才能雙贏
Block-987即使在體育Crypto領(lǐng)域,人們的目光仍然集中在FTX上。隨著... -
簡訊:前端單元測試,更進(jìn)一步
前端測試@2022如果從2014年Jest的第一個版本發(fā)布開始計算,前端開發(fā)... -
焦點熱訊:劉強(qiáng)東這波操作秀
近日,劉強(qiáng)東發(fā)布京東全員信,信中提到:自2023年1月1日起,逐步為...