Golang - map如何缩容

基本分析

在 Go 底层源码 src/runtime/map.go 中，扩缩容的处理方法是 grow 为前缀的方法来处理的。

其中扩缩容涉及到的是插入元素的操作，对应 mapassign 方法：

func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
  ...
 if !h.growing() && (overLoadFactor(h.count+1, h.B) || tooManyOverflowBuckets(h.noverflow, h.B)) {
  hashGrow(t, h)
  goto again
 }
  ...
}
func (h *hmap) growing() bool {
 return h.oldbuckets != nil
}
func overLoadFactor(count int, B uint8) bool {
 return count > bucketCnt && uintptr(count) > loadFactorNum*(bucketShift(B)/loadFactorDen)
}
func tooManyOverflowBuckets(noverflow uint16, B uint8) bool {
 if B > 15 {
  B = 15
 } 
 return noverflow >= uint16(1)<<(B&15)
}　

核心看到针对扩缩容的判断逻辑：

当前没有在扩容：条件为 oldbuckets 不为 nil。

是否可以进行扩容：条件为 hmap.count> hash 桶数量 (2^B)*6.5。其中 hmap.count 指的是map 的数据数目， 2^B 仅指 hash 数组的大小，不包含溢出桶。

是否可以进行缩容：条件为溢出桶（noverflow）的数量 >= 32768（1<<15）。

可以关注到，无论是扩容还是缩容，其都是由 hashGrow 方法进行处理：

func hashGrow(t *maptype, h *hmap) {
 bigger := uint8(1)
 if !overLoadFactor(h.count+1, h.B) {
  bigger = 0
  h.flags |= sameSizeGrow
 }
  ...
}

若是扩容，则 bigger 为 1，也就是 B+1。代表 hash 表容量扩大 1 倍。不满足就是缩容，也就是 hash 表容量不变。

可以得出结论：map 的扩缩容的主要区别在于 hmap.B 的容量大小改变。而缩容由于 hmap.B 压根没变，内存空间的占用也是没有变化的。

带来的隐患

这种方式其实是存在运行隐患的，也就是导致在删除元素时，并不会释放内存，使得分配的总内存不断增加。如果一个不小心，拿 map 来做大 key/value 的存储，也不注意管理，很容易就内存爆了。

也就是 Go 语言的 map 目前实现的是 “伪缩容”，仅针对溢出桶过多的情况。若是触发缩容，hash 数组的占用的内存大小不变（等量扩容）。

若要实现 ”真缩容“，Go Contributor @josharian 表示目前唯一可用的解决方法是：创建一个新的 map 并从旧的 map 中复制元素。

示例如下：

old := make(map[int]int, 9999999)
new := make(map[int]int, len(old))
for k, v := range old {
    new[k] = v
}
old = new
...

为什么不支持缩容

下述内容会主要基于如下两个 issues 和 proposal 来分析：

• 《runtime: shrink map as elements are deleted[1]》
• 《proposal: runtime: add way to clear and reuse a map's working storage[2]》

目前 map 的缩容处理起来比较棘手，最早的 issues 是 2016 年提出的，也有人提过一些提案，但都因为种种原因被拒绝了。

简单来讲，就是没有找到一个很好的方法实现，存在明确的实现成本问题，没办法很方便的 ”告诉“ Go 运行时，我要：

• 记得保留存储空间，我要立即重用 map。
• 赶紧释放存储空间，map 从现在开始会小很多。

抽象来看症结是：需要保证增长结果在下一个开始之前完成，此处的增长指的是 ”从小到大，从一个大小到相同大小，从大到小“ 的复杂过程。

这属于一个多重 case，从而导致也就一直拖着，慢慢想。