go语言map底层及扩容机制原理详解(下)

前言

上文对Go map的底层数据结构有所了解，并对其扩容机制的步骤进行简略的描述。本文将会详细地去解释Go map扩容机制的详细原理。

1. 触发扩容操作

在go语言中，当我们插入一个元素到hmap时，会有以下两种情况：

1. 若元素存在，则更新元素的val
2. 若元素不存在，则将该元素插入到map中。

此处的插入操作并不是简单的找到一个空余空间插入，而是在插入之前，要先判断map是否需要扩容以及是否正在进行扩容操作。
因为当map非常大的情况下，每次迁移大量的数据，会出现长时间的暂停。在go1.8版本以后，这个步骤采用来分批迁移的策略：即每次向map添加新元素或查找时，都会迁移一小部分元素，避免长时间的暂停。

// 如果我们达到了最大负载因子×容量的阈值，或者我们有太多的溢出桶，
// 并且我们还没有处于增长中，那么开始增长。
if !h.growing() && (overLoadFactor(h.count+1, h.B) || tooManyOverflowBuckets(h.noverflow, h.B)) {
	hashGrow(t, h)
	goto again 
}

// growing 报告 h 是否正在扩容。扩容可能是到相同的大小或更大。
// 通过判断oldbuckets是否为nil来判断是否扩容完成
func (h *hmap) growing() bool {
	return h.oldbuckets != nil
}

因此，当进行查询或插入操作时，若map的元素数量超过了负载因子×容量的阈值或太多的桶溢出且没有正在发生扩容操作，就会触发扩容。

2. 触发扩容的条件

上文我们分析了触发扩容操作需要达到负载因子和容量乘积的阈值或桶溢出过多。那么它的底层到底是如何具体进行判断实现的呢？
Go的底层主要内置了两个函数来判断,分别是overLoadFactor和tooManyOverflowBuckets1:

const (
	// 一个桶可以容纳的键/元素对的最大数量。
	bucketCntBits = 3
	bucketCnt     = 1 << bucketCntBits // 相当于2^3 = 8

	// 触发增长的桶的最大平均负载是6.5。
	// 表示为 loadFactorNum/loadFactorDen，以允许使用整数数学运算。
	loadFactorNum = 13
	loadFactorDen = 2
)
// bucketShift 返回 1<<b，为了优化代码生成。
func bucketShift(b uint8) uintptr {
	// 通过掩码处理移位数量，可以省略溢出检查。
	return uintptr(1) << (b & (goarch.PtrSize*8 - 1))
}

// overLoadFactor 报告将 count 个项放置在 1<<B 个桶中是否超过负载因子。
func overLoadFactor(count int, B uint8) bool {
	// 如果 count 大于每个桶能容纳的元素数量（bucketCnt），并且
	// count 大于负载因子允许的最大元素数量（loadFactorNum*(bucketShift(B)/loadFactorDen)），
	// 则返回 true，表示超过负载因子。
	return count > bucketCnt && uintptr(count) > loadFactorNum*(bucketShift(B)/loadFactorDen)
}

// tooManyOverflowBuckets 报告对于具有 1<<B 个桶的 map 而言，noverflow 个溢出桶是否太多。
// 注意这些溢出桶大部分必须在稀疏使用中；
// 如果使用密集，那么我们已经触发了常规的 map 增长。
func tooManyOverflowBuckets(noverflow uint16, B uint8) bool {
	// 如果阈值过低，我们会做额外的工作。
	// 如果阈值过高，那么增长和收缩的 map 可以保留大量未使用的内存。
	// “太多”意味着（大约）与常规桶一样多的溢出桶。
	// 有关更多详细信息，请参阅 incrnoverflow。
	if B > 15 {
		B = 15
	}
	// 编译器在这里看不到 B < 16；掩蔽 B 以生成更短的移位代码。
	return noverflow >= uint16(1)<<(B&15)
}

正在速更…