Go map發(fā)生內(nèi)存泄漏解決方法

更新時(shí)間：2022年11月13日 14:52:52 作者：Stefno

這篇文章主要介紹了Go map發(fā)生內(nèi)存泄漏解決方法詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

正文

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

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

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

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

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

在 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 是裝載因子，用來衡量平均一個(gè) bucket 里有多少個(gè) key。

查看占用的內(nèi)存數(shù)量

如何查看占用的內(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 里的，按理說，寫入 kv 與否，這些 bucket 占用的內(nèi)存都在那里。換句話說，寫入 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。搬遷的過程可以參考前面提到的那篇 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 大小超過 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)到一定值，之后即使把元素都刪了也無濟(jì)于事。內(nèi)存占用還是在，因?yàn)?buckets 占用的內(nèi)存不會(huì)少。