深入理解 Go map （2）—— 扩容

亚洲第一中锋_哈达迪

已于 2023-05-30 00:14:40 修改

阅读量1k

点赞数 2

文章标签： golang 数据结构

于 2023-03-21 23:41:09 首次发布

本文链接：https://blog.csdn.net/qq_39383767/article/details/129700263

版权

两种扩容方式

当调用mapassign方法时，如果不是更新而是新增，就需要在执行新增操作前判断是否需要扩容：

if !h.growing() && (overLoadFactor(h.count+1, h.B) || tooManyOverflowBuckets(h.noverflow, h.B)) {
   hashGrow(t, h)
   goto again // Growing the table invalidates everything, so try again
}

当没有正在扩容，元素太多或者太多桶时就会触发扩容

怎么判断是否元素过多呢？

func overLoadFactor(count int, B uint8) bool {
   return count > bucketCnt && uintptr(count) > loadFactorNum*(bucketShift(B)/loadFactorDen)
}

元素大于8个
并且元素数量大于6.5 * (2 ^B)，即平均每个桶中元素数量大于6.5个

假设所有桶都装满，负载因子是8，那么当负载因子是6.5时，表示平均来说所有桶几乎快装满了，每次查找和插入，定位到每个桶后平均还要比较3,4次，效率很低，此时扩容是很有必要的。最理想的情况是，每个桶的负载因子都是1，这样只需要一次比较就能完成查找和插入操作

怎么判断是否有太多桶呢？

func tooManyOverflowBuckets(noverflow uint16, B uint8) bool {
   if B > 15 {
      B = 15
   }
   return noverflow >= uint16(1)<<(B&15)
}

当B <= 15时，判断溢出桶的数量是否大于等于 (2 ^ B)
当B > 15时，判断溢出桶的数量是否大于等于 (2 ^ 15)

虽然每个桶的平均负载不高，但是有大量的溢出桶，此时查找和插入效率也会比较低，因为键值对分散在各个溢出桶中，需要不断地去溢出桶中查找插入

造成这种现象的原因不外乎是不断往map中添加数据，导致创建了大量溢出桶，但平均负载因子达不到6.5，不会触发上一个扩容条件，接着又删除了大量数据，使得大部分桶是空的。但是查找不存在的key，或插入一个新的键值对时，必须要遍历所有的溢出桶，这样会执行大量无效的操作

这两种情况go采用的扩容策略不同

元素过多时，进行翻倍扩容：这种情况的问题就是buckets数量太少了，会将map中桶的数量会翻倍，即hmap.B+=1
溢出桶过多时，进行等量扩容：将桶中的元素重新排列，使其更紧密，以缩减溢出桶的数量
那如果这两种情况都满足呢？
- 会进行翻倍扩容

如果判断需要扩容，就会调用hashGrow方法：

func hashGrow(t *maptype, h *hmap) {
   bigger := uint8(1)
   if !overLoadFactor(h.count+1, h.B) {
      bigger = 0
      h.flags |= sameSizeGrow
   }
   // 将原来的buckets挂在oldbuckets下
   oldbuckets := h.buckets
   // 根据不同的扩容情况，创建两倍容量的buckets数组，或者等量的bucket数组
   newbuckets, nextOverflow := makeBucketArray(t, h.B+bigger, nil)

   // 将遍历标志转成老的遍历标志
   flags := h.flags &^ (iterator | oldIterator)
   if h.flags&iterator != 0 {
      flags |= oldIterator
   }
   
   
   h.B += bigger
   h.flags = flags
   h.oldbuckets = oldbuckets
   h.buckets = newbuckets
   h.nevacuate = 0
   h.noverflow = 0

   if h.extra != nil && h.extra.overflow != nil {
      // Promote current overflow buckets to the old generation.
      if h.extra.oldoverflow != nil {
         throw("oldoverflow is not nil")
      }
      h.extra.oldoverflow = h.extra.overflow
      h.extra.overflow = nil
   }
   if nextOverflow != nil {
      if h.extra == nil {
         h.extra = new(mapextra)
      }
      h.extra.nextOverflow = nextOverflow
   }
}

hashGrow方法根据是否是翻倍扩容，申请了两倍原buckets容量的空间，或者等量的空间，并更新了h.B，将迁移进度nevacuate 置位0就返回了，并没有真正执行迁移操作

如果有大量的 key/value 需要搬迁，会非常影响性能。因此 Go map 的扩容采取了一种称为“渐进式”的方式，原有的 key/value 并不会一次性搬迁完毕，每次最多只会搬迁 2 个 bucket

具体迁移操作

那么何时执行搬迁操作呢？

在mapassign和mapdelete方法中，即每次插入，更新或删除键值对前会执行如下代码：

if h.growing() {
   growWork(t, h, bucket)
}

如果正在扩容，就执行growwork

func growWork(t *maptype, h *hmap, bucket uintptr) {
   evacuate(t, h, bucket&h.oldbucketmask())
   if h.growing() {
      evacuate(t, h, h.nevacuate)
   }
}

首先会尝试把当前key的hash值对应的老桶删除进行搬迁，然后按照h.nevacuate指示的进度再搬迁一个桶

搬迁的目的就是将老buckets的数据搬迁到新的 buckets，根据前面的分析可以知道，如果是翻倍扩容，新的 buckets 数量是之前的两倍，如果是等量扩容，新的 buckets 数量和之前相等。

对于等量扩容，从老的 buckets 搬迁到新的 buckets，由于 bucktes 数量不变，因此可以按序号来搬，比如原来在 0 号 bucktes，到新的地方后，仍然放在 0 号 buckets。

对于翻倍扩容，要重新计算 key 的哈希，才能决定它到底落在哪个 bucket。例如，原来 B = 5，计算出 key 的哈希后，只用看它的低 5 位，就能决定它落在哪个 bucket。扩容后，B 变成了 6，因此需要多看一位，它的低 6 位决定 key 落在哪个 bucket

虽然说是看低6位，但由于低5位没变，因此也只有两种选择，假设扩容前在第X个桶中：

如果第6位为1，就落入新桶的第X + 2^B 个桶中
如果第6位为0，落入新桶的X个桶中，和之前一样

理解了这个，再看看具体搬迁每个桶的操作就简单多了：

func evacuate(t *maptype, h *hmap, oldbucket uintptr) {
   b := (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
   newbit := h.noldbuckets()
   if !evacuated(b) {
      var xy [2]evacDst
      
      // 搬迁到x位置
      x := &xy[0]
      x.b = (*bmap)(add(h.buckets, oldbucket*uintptr(t.bucketsize)))
      x.k = add(unsafe.Pointer(x.b), dataOffset)
      x.e = add(x.k, bucketCnt*uintptr(t.keysize))

      if !h.sameSizeGrow() {      
         // 要么搬迁到y位置
         y := &xy[1]
         y.b = (*bmap)(add(h.buckets, (oldbucket+newbit)*uintptr(t.bucketsize)))
         y.k = add(unsafe.Pointer(y.b), dataOffset)
         y.e = add(y.k, bucketCnt*uintptr(t.keysize))
      }

      for ; b != nil; b = b.overflow(t) {
         k := add(unsafe.Pointer(b), dataOffset)
         e := add(k, bucketCnt*uintptr(t.keysize))
         for i := 0; i < bucketCnt; i, k, e = i+1, add(k, uintptr(t.keysize)), add(e, uintptr(t.elemsize)) {
            top := b.tophash[i]
            if isEmpty(top) {
               b.tophash[i] = evacuatedEmpty
               continue
            }
            if top < minTopHash {
               throw("bad map state")
            }
            k2 := k
            if t.indirectkey() {
               k2 = *((*unsafe.Pointer)(k2))
            }
            var useY uint8
            if !h.sameSizeGrow() {             
               hash := t.hasher(k2, uintptr(h.hash0))
               // 这个if主要处理float64，忽略
               if h.flags&iterator != 0 && !t.reflexivekey() && !t.key.equal(k2, k2) {
                  
                  useY = top & 1
                  top = tophash(hash)
               } else {
                  if hash&newbit != 0 {
                     useY = 1
                  }
               }
            }

            if evacuatedX+1 != evacuatedY || evacuatedX^1 != evacuatedY {
               throw("bad evacuatedN")
            }

            b.tophash[i] = evacuatedX + useY // evacuatedX + 1 == evacuatedY
            dst := &xy[useY]                 // evacuation destination

            if dst.i == bucketCnt {
               dst.b = h.newoverflow(t, dst.b)
               dst.i = 0
               dst.k = add(unsafe.Pointer(dst.b), dataOffset)
               dst.e = add(dst.k, bucketCnt*uintptr(t.keysize))
            }
            dst.b.tophash[dst.i&(bucketCnt-1)] = top // mask dst.i as an optimization, to avoid a bounds check
            if t.indirectkey() {
               *(*unsafe.Pointer)(dst.k) = k2 // copy pointer
            } else {
               typedmemmove(t.key, dst.k, k) // copy elem
            }
            if t.indirectelem() {
               *(*unsafe.Pointer)(dst.e) = *(*unsafe.Pointer)(e)
            } else {
               typedmemmove(t.elem, dst.e, e)
            }
            dst.i++          
            dst.k = add(dst.k, uintptr(t.keysize))
            dst.e = add(dst.e, uintptr(t.elemsize))
         }
      }
      // 清空这片空间
      if h.flags&oldIterator == 0 && t.bucket.ptrdata != 0 {
         b := add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)       
         ptr := add(b, dataOffset)
         n := uintptr(t.bucketsize) - dataOffset
         memclrHasPointers(ptr, n)
      }
   }

   if oldbucket == h.nevacuate {
      // 推进搬迁进度
      advanceEvacuationMark(h, t, newbit)
   }
}

搬迁单个桶的整体流程为：

遍历该桶，以及其链接的所有溢出桶，遍历桶中的每个键值对
准备两个变量x，y。每个键值对要么搬迁到x代表的位置，要么搬迁到y代表的位置
实际的搬迁操作比较简单，将源 key/value 值 copy 到目的地相应的位置，或者copy指针过去
同时将老桶tophash对于位置设置为
1. evacuatedX ：已经搬迁到新桶的前半部分
2. evacuatedY ：已经搬迁到新桶的后半部分
3. evacuatedEmpty：该槽位对应的为空，且该桶已经被搬迁

这3个常量的定义如下：

evacuatedX     = 2 // key/elem is valid.  Entry has been evacuated to first half of larger table.
evacuatedY     = 3 // same as above, but evacuated to second half of larger table.
evacuatedEmpty = 4 // cell is empty, bucket is evacuated.

设置老桶tophash的目的在于，用于快速知道老桶是否被搬迁：

func evacuated(b *bmap) bool {
   h := b.tophash[0]
   return h > emptyOne && h < minTopHash
}

至于为什么要细分这3种情况，则是用于map的遍历，下一篇文章会谈到

结束扩容

从更新迁移进度nevacuate的函数advanceEvacuationMark中可以看到，当迁移进度达到老桶的容量时，即所有的老桶都被搬迁完毕了，扩容就会结束：将oldbuckets置位nil

func advanceEvacuationMark(h *hmap, t *maptype, newbit uintptr) {
   h.nevacuate++

   stop := h.nevacuate + 1024
   if stop > newbit {
      stop = newbit
   }
   for h.nevacuate != stop && bucketEvacuated(t, h, h.nevacuate) {
      h.nevacuate++
   }
   if h.nevacuate == newbit { // newbit == # of oldbuckets
      // 结束扩容
      h.oldbuckets = nil     
      if h.extra != nil {
         h.extra.oldoverflow = nil
      }
      h.flags &^= sameSizeGrow
   }
}

扩容对读写的影响

如果一个桶正在扩容，对其进行读写操作时就没那么简单了，需要考虑新老两个桶

读

回到mapaccess1函数，当发现正在扩容，且key的hash值对应的老桶没有被搬迁时，就会去老桶中查找：

m := bucketMask(h.B)
b := (*bmap)(add(h.buckets, (hash&m)*uintptr(t.bucketsize)))
if c := h.oldbuckets; c != nil {
   if !h.sameSizeGrow() {

      m >>= 1
   }
   oldb := (*bmap)(add(c, (hash&m)*uintptr(t.bucketsize)))
   // 如果老桶没有搬迁
   if !evacuated(oldb) {
      b = oldb
   }
}

为什么可以不去新桶中找？因为如果在扩容的过程中，在新桶的对应位置上插入或更新了新的键值对，那在前一步就会把其对应的老桶迁移，而这里发现老桶并没有迁移，可以断定新桶中一定没有期望的数据，只用在老桶中找就完事了

写

回到mapassign函数，在执行正在的写操作之前会判断，如果正在扩容，会确保把key的hash值对应的老桶已经搬迁完毕，即如果没搬迁老桶就搬迁老桶，然后后续的写操作只会针对新桶

亚洲第一中锋_哈达迪

关注

2
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
深入理解 Go map （2）—— 扩容

当调用mapassign当没有正在扩容，元素太多或者太多桶时就会触发扩容怎么判断是否元素过多呢？假设所有桶都装满，负载因子是8，那么当负载因子是6.5时，表示平均来说所有桶了，每次查找和插入，定位到每个桶后平均还要比较3,4次，，此时扩容是很有必要的。最理想的情况是，每个桶的负载因子都是1，这样只需要一次比较就能完成查找和插入操作怎么判断是否有太多桶呢？虽然每个桶的平均负载不高，但是有大量的溢出桶，此时查找和插入效率也会比较低，因为键值对分散在各个溢出桶中，需要不断地去溢出桶中查找插入。
复制链接

扫一扫