Go Runtime hashmap實現

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

前兩天有小夥伴問道是否看過 Go 語言 map 的實現，當時還真沒看過，於是就花了一點時間看了一遍 runtime 源碼中的 hashmap 實現。map 的底層實現就是一個 hash 表，大體結構上和平時在腦海裡的 hash 表差不多，但確實有很多細節(“Devils in the details”)。

hashmap 通過一個 bucket 數組實現，所有元素將被 hash 到數組中的 bucket 中，bucket 填滿後，將通過一個 overflow 指標來擴充一個 bucket 出來形成鏈表，也就是解決衝突問題。這也就是一個基本的 hash 表結構，沒什麼新奇的東西，下面總結一些細節吧。

1. 注意一個 bucket 並不是只能儲存一個 key/value 對，而是可以儲存8個 key/value 對。每個 bucket 由 header 和 data 兩部分組成，data 部分的記憶體大小為：(sizeof(key) + sizeof(value)) * 8，也就是要儲存8對 key/value，這8對 key/value 在 data 記憶體中的儲存順序是：key0key1…key7value0value1…value7，是按照順序先依次儲存8個 key 值，然後儲存對應的8個 value。 為什麼不是儲存為 key0value0…key7value7 呢？主要是方便訪問吧。
2. 如果 key, value 的類型大小超過了128位元組，將不會直接儲存值，而是儲存其指標。
3. bucket 的 header 部分有一個 uint8 tophash[8] 數組，這個數組將用來儲存8個 key 的 hash 值的高8位值。比如：tophash[0] 儲存的值就是 hash(key0) » (64 - 8)。儲存了一個 key 的 hash 高8位部分，在尋找/刪除/插入一個 key 的時候，可以先判斷兩個 key hash 的高8位是否相等，如果不等，那就根本不用去比較 key 的內容。所以這裡儲存一下 hash 值的高8位可以作為第一步的粗略過濾，不少時候可以省掉比較兩個 key 的內容，因為比較兩個 key 是否相等的代價遠比兩個 uint8 的代價高。當然，這裡如果儲存整個 hash 值，而不僅僅是高8位的話，判斷效果將更好，但記憶體的佔用就會多很多了。
4. bucket 的8個 key/value 空間如果都填滿後，就會分配新的 bucket，通過 overflow 指標串聯起來。注意這個鏈表指標被命名為 overflow，代表的正是 bucket 溢出了，這個命名感覺很好，hash 表實現的時候我們應該努力避免 bucket overflow。
5. hashmap 是會自增長的，也就說隨著插入的 kv 對越來越多，初始的 bucket 數組就可以需要增長、重新hash 所有元素，效能才會好。bucket 數組增長的時機就是插入的元素個數大於了 bucket數組大小 * 6.5，為什麼是6.5，這個在代碼注釋裡有說明，主要是測試出來的經驗值。
6. hashmap 每次增長，都是重新分配一個新的 bucket 數組，新 bucket 數組是之前 bucket 數組的2倍大小。
7. hashmap 增長後，需要將老 bucket 數組中的元素拷貝到新的 bucket 數組，這個拷貝過程不是一口氣立馬完成的，而是採用了增量式的拷貝，也就是說分配了新的 bucket 數組後，並沒有立刻拷貝元素，而是等接下來每次插入一個元素的時候，才拷貝一點，隨著插入的動作增多，逐漸就將全部元素拷貝到了新的 bucket 數組中。
8. 在 make 一個 map 對象的時候，如果不指定大小的話，bucket 數組預設就是1了，隨著插入的元素增多，就會增長成2，4，8，16等。可以看出不指定初始化大小的map，很可能要經曆很多次的增長、元素拷貝。我們應該給 map 指定一個合適的大小值。

暫時就總結這麼一點了。。。

浙江省圖空調開得真冷啊，冷死我了，我要出去曬會太陽了。