Golang map底層實現原理解析

在開發過程中，map是必不可少的數據結構，在Golang中，使用map或多或少會遇到與其他語言不一樣的體驗，比如訪問不存在的元素會返回其類型的空值、map的大小究竟是多少，爲什麼會報"cannot take the address of"錯誤，遍歷map的隨機性等等。
本文希望通過研究map的底層實現，以解答這些疑惑。
基於Golang 1.8.3

1. 數據結構及內存管理

hashmap的定義位於 src/runtime/hashmap.go 中，首先我們看下hashmap和bucket的定義：

 

type hmap struct {
    count     int    // 元素的個數
    flags     uint8  // 狀態標誌
    B         uint8  // 可以最多容納 6.5 * 2 ^ B 個元素，6.5爲裝載因子
    noverflow uint16 // 溢出的個數
    hash0     uint32 // 哈希種子

    buckets    unsafe.Pointer // 桶的地址
    oldbuckets unsafe.Pointer // 舊桶的地址，用於擴容
    nevacuate  uintptr        // 搬遷進度，小於nevacuate的已經搬遷
    overflow *[2]*[]*bmap 
}

其中，overflow是一個指針，指向一個元素個數爲2的數組，數組的類型是一個指針，指向一個slice，slice的元素是桶(bmap)的地址，這些桶都是溢出桶；爲什麼有兩個？因爲Go map在hash衝突過多時，會發生擴容操作，爲了不全量搬遷數據，使用了增量搬遷，[0]表示當前使用的溢出桶集合，[1]是在發生擴容時，保存了舊的溢出桶集合；overflow存在的意義在於防止溢出桶被gc。

 

// A bucket for a Go map.
type bmap struct {
    // 每個元素hash值的高8位，如果tophash[0] < minTopHash，表示這個桶的搬遷狀態
    tophash [bucketCnt]uint8
    // 接下來是8個key、8個value，但是我們不能直接看到；爲了優化對齊，go採用了key放在一起，value放在一起的存儲方式，
    // 再接下來是hash衝突發生時，下一個溢出桶的地址
}

tophash的存在是爲了快速試錯，畢竟只有8位，比較起來會快一點。

從定義可以看出，不同於STL中map以紅黑樹實現的方式，Golang採用了HashTable的實現，解決衝突採用的是鏈地址法。也就是說，使用數組+鏈表來實現map。特別的，對於一個key，幾個比較重要的計算公式爲:

key	hash	hashtop	bucket index
key	hash := alg.hash(key, uintptr(h.hash0))	top := uint8(hash >> (sys.PtrSize*8 - 8))	bucket := hash & (uintptr(1)<<h.B - 1)，即 hash % 2^B

例如，對於B = 3，當hash(key) = 4時， hashtop = 0， bucket = 4，當hash(key) = 20時，hashtop = 0， bucket = 4；這個例子我們在搬遷過程還會用到。

內存佈局類似於這樣：

 

hashmap-buckets

2. 創建 - makemap

map的創建比較簡單，在參數校驗之後，需要找到合適的B來申請桶的內存空間，接着便是穿件hmap這個結構，以及對它的初始化。

makemap

3. 訪問 - mapaccess

對於給定的一個key，可以通過下面的操作找到它是否存在

 

image.png

方法定義爲

 

// returns key, if not find, returns nil
func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer 

// returns key and exist. if not find, returns nil, false
func mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool)

// returns both key and value. if not find, returns nil, nil
func mapaccessK(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, unsafe.Pointer)

可見在找不到對應key的情況下，會返回nil

4. 分配 - mapassign

爲一個key分配空間的邏輯，大致與查找類似；但增加了寫保護和擴容的操作；注意，分配過程和刪除過程都沒有在oldbuckets中查找，這是因爲首先要進行擴容判斷和操作；如下：

 

assign

擴容是整個hashmap的核心算法，我們放在第6部分重點研究。

新建一個溢出桶，並將其拼接在當前桶的尾部，實現了類似鏈表的操作：

 

// 獲取當前桶的溢出桶
func (b *bmap) overflow(t *maptype) *bmap {
    return *(**bmap)(add(unsafe.Pointer(b), uintptr(t.bucketsize)-sys.PtrSize))
}

// 設置當前桶的溢出桶
func (h *hmap) setoverflow(t *maptype, b, ovf *bmap) {
    h.incrnoverflow()
    if t.bucket.kind&kindNoPointers != 0 {
        h.createOverflow()
        //重點，這裏講溢出桶append到overflow[0]的後面
        *h.overflow[0] = append(*h.overflow[0], ovf)
    }
    *(**bmap)(add(unsafe.Pointer(b), uintptr(t.bucketsize)-sys.PtrSize)) = ovf
}

5. 刪除 - mapdelete

刪除某個key的操作與分配類似，由於hashmap的存儲結構是數組+鏈表，所以真正刪除key僅僅是將對應的slot設置爲empty，並沒有減少內存；如下：

 

mapdelete

6. 擴容 - growWork

首先，判斷是否需要擴容的邏輯是

 

func (h *hmap) growing() bool {
    return h.oldbuckets != nil
}

何時h.oldbuckets不爲nil呢？在分配assign邏輯中，當沒有位置給key使用，而且滿足測試條件(裝載因子>6.5或有太多溢出通)時，會觸發hashGrow邏輯：

 

func hashGrow(t *maptype, h *hmap) {
    //判斷是否需要sameSizeGrow，否則"真"擴
    bigger := uint8(1)
    if !overLoadFactor(int64(h.count), h.B) {
        bigger = 0
        h.flags |= sameSizeGrow
    }
        // 下面將buckets複製給oldbuckets
    oldbuckets := h.buckets
    newbuckets := newarray(t.bucket, 1<<(h.B+bigger))
    flags := h.flags &^ (iterator | oldIterator)
    if h.flags&iterator != 0 {
        flags |= oldIterator
    }
    // 更新hmap的變量
    h.B += bigger
    h.flags = flags
    h.oldbuckets = oldbuckets
    h.buckets = newbuckets
    h.nevacuate = 0
    h.noverflow = 0
        // 設置溢出桶
    if h.overflow != nil {
        if h.overflow[1] != nil {
            throw("overflow is not nil")
        }
// 交換溢出桶
        h.overflow[1] = h.overflow[0]
        h.overflow[0] = nil
    }
}

OK，下面正式進入重點，擴容階段；在assign和delete操作中，都會觸發擴容growWork：

 

func growWork(t *maptype, h *hmap, bucket uintptr) {
    // 搬遷舊桶，這樣assign和delete都直接在新桶集合中進行
    evacuate(t, h, bucket&h.oldbucketmask())
        //再搬遷一次搬遷過程中的桶
    if h.growing() {
        evacuate(t, h, h.nevacuate)
    }
}

6.1 搬遷過程

一般來說，新桶數組大小是原來的2倍(在!sameSizeGrow()條件下)，新桶數組前半段可以"類比"爲舊桶，對於一個key，搬遷後落入哪一個索引中呢？

 

假設舊桶數組大小爲2^B， 新桶數組大小爲2*2^B，對於某個hash值X
若 X & (2^B) == 0，說明 X < 2^B，那麼它將落入與舊桶集合相同的索引xi中；
否則，它將落入xi + 2^B中。

例如，對於舊B = 3時，hash1 = 4，hash2 = 20，其搬遷結果類似這樣。

example.png

源碼中有些變量的命名比較簡單，容易擾亂思路，我們註明一下便於理解。

變量	釋義
x *bmap	桶x表示與在舊桶時相同的位置，即位於新桶前半段
y *bmap	桶y表示與在舊桶時相同的位置+舊桶數組大小，即位於新桶後半段
xi int	桶x的slot索引
yi int	桶y的slot索引
xk unsafe.Pointer	索引xi對應的key地址
yk unsafe.Pointer	索引yi對應的key地址
xv unsafe.Pointer	索引xi對應的value地址
yv unsafe.Pointer	索引yi對應的value地址

搬遷過程如下：

 

evacuate

總結

到目前爲止，Golang的map實現細節已經分析完畢，但不包含迭代器相關操作。通過分析，我們瞭解了map是由數組+鏈表實現的HashTable，其大小和B息息相關，同時也瞭解了map的創建、查詢、分配、刪除以及擴容搬遷原理。總的來說，Golang通過hashtop快速試錯加快了查找過程，利用空間換時間的思想解決了擴容的問題，利用將8個key(8個value)依次放置減少了padding空間等等。