快捷導(dǎo)航

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

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

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

正文

Go 程序運(yùn)行時(shí)，有些場景下會(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)勢。

最近在看《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è)長度為 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 的長度初始化為 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)建長度為 100w 的 map 所消耗的內(nèi)存大小。當(dāng)我們創(chuàng)建一個(gè)初始長度為 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 長度的 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 的長度指定為 100w，那內(nèi)存變化情況為：