文章首发:公众号 newbmiao
Dig101: dig more, simplified more and know more
在golang中,map
是一个不可或缺的存在。
它作为哈希表,简单易用,既能自动处理哈希碰撞,又能自动扩容或重新内存整理,避免读写性能的下降。
这些都要归功于其内部实现的精妙。本文尝试去通过源码去分析一下其背后的故事。
我们不会过多在源码分析上展开,只结合代码示例对其背后设计实现上做些总结,希望可以简单明了一些。
希望看完后,会让你对 map 的理解有一些帮助。网上也有很多不错的源码分析,会附到文末,感兴趣的同学自行查看下。
(本文分析基于 Mac 平台上go1.14beta1版本。长文预警 ... )
我们先简单过下map实现hash表所用的数据结构,这样方便后边讨论。
文章目录
- 0x01 map 的内部结构
- 0x02 map 的 hash 方式
- 0x03 map 的扩容方式
- 0x04 map 的初始化
- 0x05 map 的读取
- 0x06 map 的赋值
- 0x07 map 的删除
- 0x08 map 的遍历
0x01 map的内部结构
在这里我们先弄清楚map实现的整体结构
map本质是hash表(hmap
),指向一堆桶(buckets
)用来承接数据,每个桶(bmap
)能存8组k/v。
当有数据读写时,会用key
的hash找到对应的桶。
为加速hash定位桶,bmap
里记录了tophash
数组(hash的高8位)
hash表就会有哈希冲突的问题(不同key的hash值一样,即hash后都指向同一个桶),为此map使用桶后链一个溢出桶(overflow
)链表来解决当桶8个单元都满了,但还有数据需要存入此桶的问题。
剩下noverflow,oldbuckets,nevacuate,oldoverflow
会用于扩容,暂时先不展开
具体对应的数据结构详细注释如下:
(虽然多,先大致过一遍,后边遇到会在提到)
// runtime/map.go
// A header for a Go map.
type hmap struct {
//用于len(map)
count int
//标志位
// iterator = 1 // 可能有遍历用buckets
// oldIterator = 2 // 可能有遍历用oldbuckets,用于扩容期间
// hashWriting = 4 // 标记写,用于并发读写检测
// sameSizeGrow = 8 // 用于等大小buckets扩容,减少overflow桶
flags uint8
// 代表可以最多容纳loadFactor * 2^B个元素(loadFactor=6.5)
B uint8
// overflow桶的计数,当其接近1<<15 - 1时为近似值
noverflow uint16
// 随机的hash种子,每个map不一样,减少哈希碰撞的几率
hash0 uint32
// 当前桶,长度为(0-2^B)
buckets unsafe.Pointer
// 如果存在扩容会有扩容前的桶
oldbuckets unsafe.Pointer
// 迁移数,标识小于其的buckets已迁移完毕
nevacuate uintptr
// 额外记录overflow桶信息,不一定每个map都有
extra *mapextra
}
// 额外记录overflow桶信息
type mapextra struct {
overflow *[]*bmap
oldoverflow *[]*bmap
// 指向下一个可用overflow桶
nextOverflow *bmap
}
const(
// 每个桶8个k/v单元
BUCKETSIZE = 8
// k或v类型大小大于128转为指针存储
MAXKEYSIZE = 128
MAXELEMSIZE = 128
)
// 桶结构 (字段会根据key和elem类型动态生成,见下边bmap)
type bmap struct {
// 记录桶内8个单元的高8位hash值,或标记空桶状态,用于快速定位key
// emptyRest = 0 // 此单元为空,且更高索引的单元也为空
// emptyOne = 1 // 此单元为空
// evacuatedX =