不知道你有沒有聽過這么一句：在使用 map 時盡量不要在 big map 中保存指針。好吧，你現(xiàn)在已經(jīng)聽過了：）為什么呢？原因在于 Go 語言的垃圾回收器會掃描標記 map 中的所有元素，GC 開銷相當大，直接GG。
成都創(chuàng)新互聯(lián)公司主要業(yè)務有網(wǎng)站營銷策劃、成都網(wǎng)站設計、做網(wǎng)站、微信公眾號開發(fā)、小程序開發(fā)、H5建站、程序開發(fā)等業(yè)務。一次合作終身朋友，是我們奉行的宗旨；我們不僅僅把客戶當客戶，還把客戶視為我們的合作伙伴，在開展業(yè)務的過程中，公司還積累了豐富的行業(yè)經(jīng)驗、成都全網(wǎng)營銷推廣資源和合作伙伴關系資源，并逐漸建立起規(guī)范的客戶服務和保障體系。
這兩天在《Mastering Go》中看到 GC 這一章節(jié)里面對比 map 和 slice 在垃圾回收中的效率對比，書中只給出結論沒有說明理由，這我是不能忍的，于是有了這篇學習筆記。扯那么多，Show Your Code
這是一個簡單的測試程序，保存字符串的 map 和 保存整形的 map GC 的效率相差幾十倍，是不是有同學會說明明保存的是 string 哪有指針？這個要說到 Go 語言中 string 的底層實現(xiàn)了，源碼在 src/runtime/string.go里，可以看到 string 其實包含一個指向數(shù)據(jù)的指針和一個長度字段。注意這里的是否包含指針，包括底層的實現(xiàn)。
Go 語言的 GC 會遞歸遍歷并標記所有可觸達的對象，標記完成之后將所有沒有引用的對象進行清理。掃描到指針就會往下接著尋找，一直到結束。
Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結構實現(xiàn)的，通過 優(yōu)化的拉鏈法 解決哈希沖突，每個 bucket 可以保存 8 對鍵值，在 8 個鍵值對數(shù)據(jù)后面有一個 overflow 指針，因為桶中最多只能裝 8 個鍵值對，如果有多余的鍵值對落到了當前桶，那么就需要再構建一個桶（稱為溢出桶），通過 overflow 指針鏈接起來。
因為 overflow 指針的緣故，所以無論 map 保存的是什么，GC 的時候就會把所有的 bmap 掃描一遍，帶來巨大的 GC 開銷。官方 issues 就有關于這個問題的討論， runtime: Large maps cause significant GC pauses #9477
無腦機翻如下：
如果我們有一個map [k] v，其中k和v都不包含指針，并且我們想提高掃描性能，則可以執(zhí)行以下操作。
將“ allOverflow [] unsafe.Pointer”添加到 hmap 并將所有溢出存儲桶存儲在其中。 然后將 bmap 標記為noScan。 這將使掃描非?？欤驗槲覀儾粫呙枞魏斡脩魯?shù)據(jù)。
實際上，它將有些復雜，因為我們需要從allOverflow中刪除舊的溢出桶。 而且它還會增加 hmap 的大小，因此也可能需要重新整理數(shù)據(jù)。
最終官方在 hmap 中增加了 overflow 相關字段完成了上面的優(yōu)化，這是具體的 commit 地址。
下面看下具體是如何實現(xiàn)的，源碼基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中
通過注釋可以看出，如果 map 中保存的鍵值都不包含指針（通過 Haspointers 判斷），就使用一個 uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段，uintptr 類型在 GO 語言中就是個大小可以保存得下指針的整數(shù)，不是指針，就相當于實現(xiàn)了 將 bmap 標記為 noScan， GC 的時候就不會遍歷完整個 map 了。隨著不斷的學習，愈發(fā)感慨 GO 語言中很多模塊設計得太精妙了。
差不多說清楚了，能力有限，有不對的地方歡迎留言討論，源碼位置還是問的群里大佬 _
golang 中 map的實現(xiàn)結構為： 哈希表 + 鏈表。 其中鏈表，作用是當發(fā)生hash沖突時，拉鏈法生成的結點。
可以看到， []bmap 是一個hash table， 每一個 bmap是我們常說的“桶”。 經(jīng)過hash 函數(shù)計算出來相同的hash值， 放到相同的桶中。 一個 bmap中可以存放 8個 元素， 如果多出8個，則生成新的結點，尾接到隊尾。
以上是只是靜態(tài)文件 src/runtime/map.go 中的定義。 實際上編譯期間會給它加料 ，動態(tài)地創(chuàng)建一個新的結構：
上圖就是 bmap的內(nèi)存模型， HOB Hash 指的就是 top hash。 注意到 key 和 value 是各自放在一起的，并不是 key/value/key/value/... 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding 字段，節(jié)省內(nèi)存空間。
每個 bmap設計成 最多只能放 8 個 key-value 對 ，如果有第 9 個 key-value 落入當前的 bmap，那就需要再構建一個 bmap，通過 overflow 指針連接起來。
map創(chuàng)建方法:
我們實際上是通過調(diào)用的 makemap ，來創(chuàng)建map的。實際工作只是初始化了hmap中的各種字段，如：設置B的大小， 設置hash 種子 hash 0.
注意 :
makemap 返回是*hmap 指針， 即 map 是引用對象， 對map的操作會影響到結構體內(nèi)部 。
使用方式
對應的是下面兩種方法
map的key的類型，實現(xiàn)了自己的hash 方式。每種類型實現(xiàn)hash函數(shù)方式不一樣。
key 經(jīng)過哈希計算后得到hash值，共 64 個 bit 位。 其中后B 個bit位置， 用來定位當前元素落在哪一個桶里， 高8個bit 為當前 hash 值的top hash。 實際上定位key的過程是一個雙重循環(huán)的過程， 外層循環(huán)遍歷 所有的overflow， 內(nèi)層循環(huán)遍歷 當前bmap 中的 8個元素 。
舉例說明： 如果當前 B 的值為 5， 那么buckets 的長度 為 2^5 = 32。假設有個key 經(jīng)過hash函數(shù)計算后，得到的hash結果為：
外層遍歷bucket 中的鏈表
內(nèi)層循環(huán)遍歷 bmap中的8個 cell
建議先不看此部分內(nèi)容，看完后續(xù) 修改 map中元素 - 擴容 操作后 再回頭看此部分內(nèi)容。
擴容前的數(shù)據(jù)：
等量擴容后的數(shù)據(jù)：
等量擴容后，查找方式和原本相同， 不多做贅述。
兩倍擴容后的數(shù)據(jù)
兩倍擴容后，oldbuckets 的元素，可能被分配成了兩部分。查找順序如下：
此處只分析 mapaccess1 ,。 mapaccess2 相比 mapaccess1 多添加了是否找到的bool值， 有興趣可自行看一下。
使用方式：
步驟如下：
擴容條件 ：
擴容的標識 ： h.oldbuckets ！= nil
假設當前定位到了新的buckets的3號桶中，首先會判斷oldbuckets中的對應的桶有沒有被搬遷過。 如果搬遷過了，不需要看原來的桶了，直接遍歷新的buckets的3號桶。
擴容前：
等量擴容結果
雙倍擴容會將old buckets上的元素分配到x， y兩個部key 1 B == 0 分配到x部分，key 1 B == 1 分配到y(tǒng)部分
注意： 當前只對雙倍擴容描述， 等量擴容只是重新填充了一下元素， 相對位置沒有改變。
假設當前map 的B == 5，原本元素經(jīng)過hash函數(shù)計算的 hash 值為：
因為雙倍擴容之后 B = B + 1，此時B == 6。key 1 B == 1, 即 當前元素rehash到高位，新buckets中 y 部分. 否則 key 1 B == 0 則rehash到低位，即x 部分。
使用方式：
可以看到，每一遍歷生成迭代器的時候，會隨機選取一個bucket 以及 一個cell開始。 從前往后遍歷，再次遍歷到起始位置時，遍歷完成。
sync.Map是1.9才推薦的并發(fā)安全的map，除了互斥量以外，還運用了原子操作，所以在這之前，有必要了解下 Go語言——原子操作
go1.10\src\sync\map.go
entry分為三種情況：
從read中讀取key，如果key存在就tryStore。
注意這里開始需要加鎖，因為需要操作dirty。
條目在read中，首先取消標記，然后將條目保存到dirty里。（因為標記的數(shù)據(jù)不在dirty里）
最后原子保存value到條目里面，這里注意read和dirty都有條目。
總結一下Store：
這里可以看到dirty保存了數(shù)據(jù)的修改，除非可以直接原子更新read，繼續(xù)保持read clean。
有了之前的經(jīng)驗，可以猜測下load流程：
與猜測的 區(qū)別 ：
由于數(shù)據(jù)保存兩份，所以刪除考慮：
先看第二種情況。加鎖直接刪除dirty數(shù)據(jù)。思考下貌似沒什么問題，本身就是臟數(shù)據(jù)。
第一種和第三種情況唯一的區(qū)別就是條目是否被標記。標記代表刪除，所以直接返回。否則CAS操作置為nil。這里總感覺少點什么，因為條目其實還是存在的，雖然指針nil。
看了一圈貌似沒找到標記的邏輯，因為刪除只是將他變成nil。
之前以為這個邏輯就是簡單的將為標記的條目拷貝給dirty，現(xiàn)在看來大有文章。
p == nil，說明條目已經(jīng)被delete了，CAS將他置為標記刪除。然后這個條目就不會保存在dirty里面。
這里其實就跟miss邏輯串起來了，因為miss達到閾值之后，dirty會全量變成read，也就是說標記刪除在這一步最終刪除。這個還是很巧妙的。
真正的刪除邏輯：
很繞。。。。
由于go語言是一個強類型的語言，因此hashmap也是有類型的，具體體現(xiàn)在key和value都必須指定類型，比如聲明一個key為string，value也是string的map，
需要這樣做
大部分類型都能做key，某些類型是不能的，共同的特點是： 不能使用== 來比較，包括: slice, map, function
在迭代的過程中是可以對map進行刪除和更新操作的，規(guī)則如下：
golang的map是hash結構的，意味著平均訪問時間是O(1)的。同傳統(tǒng)的hashmap一樣，由一個個bucket組成:
那我們怎么訪問到對應的bucket呢，我們需要得到對應key的hash值
各個參數(shù)的意思：
目前采用的是這一行:
| 6.50 | 20.90 | 10.79 | 4.25 | 6.50 |
重慶分公司
重慶分公司
