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 { count int flags uint8 B uint8 // ... }
若我們想初始化一個長度為 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 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 會被回收掉。
當 N = 128 時,運行程序:
$ go run main2.go 0 MB 461 MB 293 MB
可以看到,當刪除瞭所有 kv 後,內存占用依然有 293 MB,這實際上是創建長度為 100w 的 map 所消耗的內存大小。當我們創建一個初始長度為 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) }
運行程序,得到 100w 長度的 map 的消耗的內存為:
$ go run main3.go 293 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) }
運行程序,B 值從 1 一直變到 18。搬遷的過程可以參考前面提到的那篇 map 文章,這裡不再贅述。
而如果我們初始化的時候直接將 map 的長度指定為 100w,那內存變化情況為:
293 MB 293 MB 293 MB
當 val 小於 128B 時,初始化 map 後內存占用量一直不變。原因是 put 操作隻是在 bucket 裡原地寫入 val,而 delete 操作則是將 val 清零,bucket 本身還在。因此,內存占用大小不變。
而當 val 大小超過 128B 後,bucket 不會直接放 val,轉而變成一個指針。我們將 N 設為 129,運行程序:
0 MB 197 MB 38 MB
雖然 map 的 bucket 占用內存量依然存在,但 val 改成指針存儲後內存占用量大大降低。且 val 被刪掉後,內存占用量確實降低瞭。
總之,map 的 buckets 數隻會增,不會降。所以在流量沖擊後,map 的 buckets 數增長到一定值,之後即使把元素都刪瞭也無濟於事。內存占用還是在,因為 buckets 占用的內存不會少。
對於 map 內存泄漏的解法
- 重啟;
- 將 val 類型改成指針;
- 定期地將 map 裡的元素全量拷貝到另一個 map 裡。
好在一般有大流量沖擊的互聯網業務大都是 toC 場景,上線頻率非常高。有的公司能一天上線好幾次,在問題暴露之前就已經重啟恢復瞭,問題不大。
以上就是Go map發生內存泄漏解決方法的詳細內容,更多關於Go map發生內存泄漏的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- Golang map實現原理深入分析
- Golang 空map和未初始化map的註意事項說明
- go map搬遷的實現
- go語言中slice,map,channl底層原理
- 源碼剖析Golang中map擴容底層的實現