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 記憶體漏失的解法：
好在一般有大流量衝擊的網際網路業務大都是 toC 場景，上線頻率非常高。有的公司能一天上線好幾次，在問題暴露之前就已經重啟恢復了，問題不大。