不知道你有沒有聽過這么一句：在使用 map 時(shí)盡量不要在 big map 中保存指針。好吧，你現(xiàn)在已經(jīng)聽過了：）為什么呢？原因在于 Go 語言的垃圾回收器會(huì)掃描標(biāo)記 map 中的所有元素，GC 開銷相當(dāng)大，直接GG。
目前成都創(chuàng)新互聯(lián)公司已為上千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站運(yùn)營(yíng)、企業(yè)網(wǎng)站設(shè)計(jì)、麻城網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
這兩天在《Mastering Go》中看到 GC 這一章節(jié)里面對(duì)比 map 和 slice 在垃圾回收中的效率對(duì)比，書中只給出結(jié)論沒有說明理由，這我是不能忍的，于是有了這篇學(xué)習(xí)筆記。扯那么多，Show Your Code
這是一個(gè)簡(jiǎn)單的測(cè)試程序，保存字符串的 map 和 保存整形的 map GC 的效率相差幾十倍，是不是有同學(xué)會(huì)說明明保存的是 string 哪有指針？這個(gè)要說到 Go 語言中 string 的底層實(shí)現(xiàn)了，源碼在 src/runtime/string.go里，可以看到 string 其實(shí)包含一個(gè)指向數(shù)據(jù)的指針和一個(gè)長(zhǎng)度字段。注意這里的是否包含指針，包括底層的實(shí)現(xiàn)。
Go 語言的 GC 會(huì)遞歸遍歷并標(biāo)記所有可觸達(dá)的對(duì)象，標(biāo)記完成之后將所有沒有引用的對(duì)象進(jìn)行清理。掃描到指針就會(huì)往下接著尋找，一直到結(jié)束。
Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的，通過 優(yōu)化的拉鏈法 解決哈希沖突，每個(gè) bucket 可以保存 8 對(duì)鍵值，在 8 個(gè)鍵值對(duì)數(shù)據(jù)后面有一個(gè) overflow 指針，因?yàn)橥爸凶疃嘀荒苎b 8 個(gè)鍵值對(duì)，如果有多余的鍵值對(duì)落到了當(dāng)前桶，那么就需要再構(gòu)建一個(gè)桶（稱為溢出桶），通過 overflow 指針鏈接起來。
因?yàn)?overflow 指針的緣故，所以無論 map 保存的是什么，GC 的時(shí)候就會(huì)把所有的 bmap 掃描一遍，帶來巨大的 GC 開銷。官方 issues 就有關(guān)于這個(gè)問題的討論， runtime: Large maps cause significant GC pauses #9477
無腦機(jī)翻如下：
如果我們有一個(gè)map [k] v，其中k和v都不包含指針，并且我們想提高掃描性能，則可以執(zhí)行以下操作。
將“ allOverflow [] unsafe.Pointer”添加到 hmap 并將所有溢出存儲(chǔ)桶存儲(chǔ)在其中。 然后將 bmap 標(biāo)記為noScan。 這將使掃描非?？?，因?yàn)槲覀儾粫?huì)掃描任何用戶數(shù)據(jù)。
實(shí)際上，它將有些復(fù)雜，因?yàn)槲覀冃枰獜腶llOverflow中刪除舊的溢出桶。 而且它還會(huì)增加 hmap 的大小，因此也可能需要重新整理數(shù)據(jù)。
最終官方在 hmap 中增加了 overflow 相關(guān)字段完成了上面的優(yōu)化，這是具體的 commit 地址。
下面看下具體是如何實(shí)現(xiàn)的，源碼基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中
通過注釋可以看出，如果 map 中保存的鍵值都不包含指針（通過 Haspointers 判斷），就使用一個(gè) uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段，uintptr 類型在 GO 語言中就是個(gè)大小可以保存得下指針的整數(shù)，不是指針，就相當(dāng)于實(shí)現(xiàn)了 將 bmap 標(biāo)記為 noScan， GC 的時(shí)候就不會(huì)遍歷完整個(gè) map 了。隨著不斷的學(xué)習(xí)，愈發(fā)感慨 GO 語言中很多模塊設(shè)計(jì)得太精妙了。
差不多說清楚了，能力有限，有不對(duì)的地方歡迎留言討論，源碼位置還是問的群里大佬 _
在使用Go語言的時(shí)候，碰到了需要對(duì)數(shù)組進(jìn)行去重操作的問題。Java語言有Set集合這個(gè)數(shù)據(jù)結(jié)構(gòu)，可以很方便的將數(shù)組轉(zhuǎn)為集合，但是Go語言沒有Set，如果僅僅是因?yàn)槿ブ夭僮骶褪謩?dòng)實(shí)現(xiàn)一個(gè)Set太繁瑣了?？梢愿鶕?jù)Go語言中的map的特性來簡(jiǎn)單實(shí)現(xiàn)一下
這個(gè)是對(duì)字符串?dāng)?shù)組去重操作。可以根據(jù)需要的類型稍作修改即可。需要注意的是只支持可以作為map鍵的結(jié)構(gòu)進(jìn)行去重！
// 先聲明map
var m1 map[string]string
// 再使用make函數(shù)創(chuàng)建一個(gè)非nil的map，nil map不能賦值
m1 = make(map[string]string)
// 最后給已聲明的map賦值
m1["a"] = "aa"
m1["b"] = "bb"
// 直接創(chuàng)建
m2 := make(map[string]string)
// 然后賦值
m2["a"] = "aa"
m2["b"] = "bb"
// 初始化 + 賦值一體化
m3 := map[string]string{
"a": "aa",
"b": "bb",
}
望采納。。
// ==========================================
// 查找鍵值是否存在
if v, ok := m1["a"]; ok {
fmt.Println(v)
} else {
fmt.Println("Key Not Found")
}
// 遍歷map
for k, v := range m1 {
fmt.Println(k, v)
}
sync.Map是1.9才推薦的并發(fā)安全的map，除了互斥量以外，還運(yùn)用了原子操作，所以在這之前，有必要了解下 Go語言——原子操作
go1.10\src\sync\map.go
entry分為三種情況：
從read中讀取key，如果key存在就tryStore。
注意這里開始需要加鎖，因?yàn)樾枰僮鱠irty。
條目在read中，首先取消標(biāo)記，然后將條目保存到dirty里。（因?yàn)闃?biāo)記的數(shù)據(jù)不在dirty里）
最后原子保存value到條目里面，這里注意read和dirty都有條目。
總結(jié)一下Store：
這里可以看到dirty保存了數(shù)據(jù)的修改，除非可以直接原子更新read，繼續(xù)保持read clean。
有了之前的經(jīng)驗(yàn)，可以猜測(cè)下load流程：
與猜測(cè)的 區(qū)別 ：
由于數(shù)據(jù)保存兩份，所以刪除考慮：
先看第二種情況。加鎖直接刪除dirty數(shù)據(jù)。思考下貌似沒什么問題，本身就是臟數(shù)據(jù)。
第一種和第三種情況唯一的區(qū)別就是條目是否被標(biāo)記。標(biāo)記代表刪除，所以直接返回。否則CAS操作置為nil。這里總感覺少點(diǎn)什么，因?yàn)闂l目其實(shí)還是存在的，雖然指針nil。
看了一圈貌似沒找到標(biāo)記的邏輯，因?yàn)閯h除只是將他變成nil。
之前以為這個(gè)邏輯就是簡(jiǎn)單的將為標(biāo)記的條目拷貝給dirty，現(xiàn)在看來大有文章。
p == nil，說明條目已經(jīng)被delete了，CAS將他置為標(biāo)記刪除。然后這個(gè)條目就不會(huì)保存在dirty里面。
這里其實(shí)就跟miss邏輯串起來了，因?yàn)閙iss達(dá)到閾值之后，dirty會(huì)全量變成read，也就是說標(biāo)記刪除在這一步最終刪除。這個(gè)還是很巧妙的。
真正的刪除邏輯：
很繞。。。。
重慶分公司
重慶分公司
