Go 程序運(yùn)行時(shí)，有些場(chǎng)景下會(huì)導(dǎo)致進(jìn)程進(jìn)入某個(gè)“高點(diǎn)”，然后就再也下不來了。
10年的五華網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營銷型網(wǎng)站建設(shè)的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整五華建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)公司從事“五華網(wǎng)站設(shè)計(jì)”,“五華網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
比如，多年前曹大寫過的一篇文章講過，在做活動(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è)長度為 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ù)量呢？用 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)存變化情況為：
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ù)增長到一定值，之后即使把元素都刪了也無濟(jì)于事。內(nèi)存占用還是在，因?yàn)?buckets 占用的內(nèi)存不會(huì)少。
對(duì)于 map 內(nèi)存泄漏的解法：
好在一般有大流量沖擊的互聯(lián)網(wǎng)業(yè)務(wù)大都是 toC 場(chǎng)景，上線頻率非常高。有的公司能一天上線好幾次，在問題暴露之前就已經(jīng)重啟恢復(fù)了，問題不大。
