开心一刻
放假，送室友坐高铁回家，临上车前，我说：“我去买几个橘子，你就站在此地，不要走动。”
室友愣了一下，说：“你TM什么时侯都不忘占我便宜。”
写在前面
最近在看Go map底层源码，看到go map的扩容机制，产生几个疑问，通过看源码能够理解，但是总感觉不够透彻，也容易忘记，在这里记录一下，以后碰到更好的解释再来记录。
- 扩容时获取map中的值的过程？
- 扩容时更改map中的值的过程？
- 扩容时删除map中的值的过程？
- 扩容因子6.5如何确定的？
扩容时获取map中的值的过程
map中获取元素的函数原型主要有以下几种：
mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer
mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool)
mapaccessK(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, unsafe.Pointer)
mapaccess1_fat(t *maptype, h *hmap, key, zero unsafe.Pointer) unsafe.Pointer
mapaccess2_fat(t *maptype, h *hmap, key, zero unsafe.Pointer) (unsafe.Pointer, bool)
mapaccess1_fast32(t *maptype, h *hmap, key uint32) unsafe.Pointer
mapaccess2_fast32(t *maptype, h *hmap, key uint32) (unsafe.Pointer, bool)
mapassign_fast32(t *maptype, h *hmap, key uint32) unsafe.Pointer
mapassign_fast32ptr(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer
mapaccess1_fast64(t *maptype, h *hmap, key uint64) unsafe.Pointer
...
mapaccess1_faststr(t *maptype, h *hmap, ky string) unsafe.Pointer
...
之所以有这么多的函数原型还是主要因为go针对各种数据类型进行了优化，加快代码的执行效率，最基本的还是要看前两个，然后与扩容时想关的代码部分如下：
func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
···
// 计算key在属于哪个常规桶
hash := t.hasher(key, uintptr(h.hash0))
m := bucketMask(h.B)
b := (*bmap)(add(h.buckets, (hash&m)*uintptr(t.bucketsize)))
// 扩容时重新定位在旧桶的位置，如果旧桶没有迁移，那么直接将旧桶赋值给b，接下来就只在旧桶中查找
if c := h.oldbuckets; c != nil {
if !h.sameSizeGrow() {
// There used to be half as many buckets; mask down one more power of two.
m >>= 1
}
oldb := (*bmap)(add(c, (hash&m)*uintptr(t.bucketsize)))
if !evacuated(oldb) {
b = oldb
}
}
// 计算tophash，开始在桶中查找元素
top := tophash(hash)
bucketloop:
for ; b != nil; b = b.overflow(t) {
for i := uintptr(0); i < bucketCnt; i++ {
···
}
}
return unsafe.Pointer(&zeroVal[0])
}
注意点：
map中查找元素的时候，如果处在扩容阶段时，不涉及迁移；
先定位到常规桶，再判断定位到的旧桶是否迁移，如果还没有迁移，直接转到旧桶中查找。
扩容时更改map中的值的过程？
map的赋值涉及的函数原型包括：
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {}
func mapassign_fast32(t *maptype, h *hmap, key uint32) unsafe.Pointer {}
func mapassign_fast32ptr(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {}
func mapassign_fast64(t *maptype, h *hmap, key uint64) unsafe.Pointer {}
func mapassign_fast64ptr(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer{}
func mapassign_faststr(t *maptype, h *hmap, s string) unsafe.Pointer {}
Go同样对于不同类型的key值进行了优化，代码逻辑大致相同。与map赋值涉及的代码如下：
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
···
again:
bucket := hash & bucketMask(h.B)
//如果正在迁移，先将key所在的旧桶迁移，然后顺便再迁移一个桶，然后将nevacuate指向下一个待迁移的桶
//可以查看growWork查看具体逻辑
if h.growing() {
growWork(t, h, bucket)
}
//在常规桶中查找key的位置，如果存在key，则更新value即可，否则寻找一个空位，然后插入key、value
b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
top := tophash(hash)
var inserti *uint8
var insertk unsafe.Pointer
var elem unsafe.Pointer
bucketloop:
···
// Did not find mapping for key. Allocate new cell & add entry.
//没有找到key值的时候，就需要增加寻找一个空位，不过会先预判是否要进入扩容阶段。
// If we hit the max load factor or we have too many overflow buckets,
// and we're not already in the middle of growing, start growing.
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
}
if inserti == nil {
// The current bucket and all the overflow buckets connected to it are full, allocate a new one.
newb := h.newoverflow(t, b)
inserti = &newb.tophash[0]
insertk = add(unsafe.Pointer(newb), dataOffset)
elem = add(insertk, bucketCnt*uintptr(t.keysize))
}
// store new key/elem at insert position
···
return elem
}
注意点：
渐进式扩容的扩容就体现在插入值的时候，在扩容的时候不仅会将key所在的旧桶迁移，并且顺带迁移一个桶，并指向下一个待迁移的桶；
该函数返回的是一个内存地址，也就是key对应的value的内存地址，将value的值放入到该内存地址中即可。应该是由其他编译代码完成
扩容时删除map中的值的过程？
map的删除涉及的函数原型包括：
func mapdelete(t *maptype, h *hmap, key unsafe.Pointer)
func mapdelete_fast32(t *maptype, h *hmap, key unsafe.Pointer)
func mapdelete_fast64(t *maptype, h *hmap, key unsafe.Pointer)
func mapdelete_faststr(t *maptype, h *hmap, key unsafe.Pointer)
具体的代码逻辑如下：
func mapdelete(t *maptype, h *hmap, key unsafe.Pointer) {
//判断是否有其他协程在操作该map对象，如果有，则报错。这也是标准map不支持并发的原因
if h.flags&hashWriting != 0 {
throw("concurrent map writes")
}
hash := t.hasher(key, uintptr(h.hash0))
// Set hashWriting after calling t.hasher, since t.hasher may panic,
// in which case we have not actually done a write (delete).
h.flags ^= hashWriting
// 如果正在迁移，则先迁移。与map赋值操作逻辑相同
bucket := hash & bucketMask(h.B)
if h.growing() {
growWork(t, h, bucket)
}
b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
bOrig := b
top := tophash(hash)
search:
for ; b != nil; b = b.overflow(t) {
for i := uintptr(0); i < bucketCnt; i++ {
····
//删除操作仅将标志位设置为emptyOne，并不清空内存，这也是需要等量扩容(伪缩容)的原因
b.tophash[i] = emptyOne
// If the bucket now ends in a bunch of emptyOne states,
// change those to emptyRest states.
// It would be nice to make this a separate function, but
// for loops are not currently inlineable.
····
notLast:
h.count--
// Reset the hash seed to make it more difficult for attackers to
// repeatedly trigger hash collisions. See issue 25237.
if h.count == 0 {
h.hash0 = fastrand()
}
break search
}
}
if h.flags&hashWriting == 0 {
throw("concurrent map writes")
}
h.flags &^= hashWriting
}
注意点：
map删除元素时的扩容也体现在插入值的时候，在扩容的时候不仅会将key所在的旧桶迁移，并且顺带迁移一个桶，并指向下一个待迁移的桶；
删除操作仅将标志位设置为emptyOne，并不清空内存，这也是需要等量扩容(伪缩容)的原因。
扩容因子6.5如何确定的？
这个值太大会导致溢出桶（overflow buckets）过多，查找效率降低，过小则会浪费存储空间。
据 Google 开发人员称，这个值是一个测试程序测量出来的一个经验值。在map.go中有数据解释。
总结
这部分写的扩容的一些相关问题如果没理解map的访问、赋值，可能不太好理解这部分内容。我自己也参考了很多优秀博客，下面把一些我觉得比较好的博客链接写出来，以后常看看。
其他相关问题：
- 桶和key的定位：我觉得map中定位key所在的桶依靠的是hash值的低B位（B就是hmap结构体中的B），有的博客中写的低8位我觉得不太准确。源码中相关代码是这样写的:
// bucketShift returns 1<<b, optimized for code generation.
func bucketShift(b uint8) uintptr {
// Masking the shift amount allows overflow checks to be elided.
return uintptr(1) << (b & (sys.PtrSize*8 - 1))
}
// bucketMask returns 1<<b - 1, optimized for code generation.
func bucketMask(b uint8) uintptr {
return bucketShift(b) - 1
}
明显不是靠低八位来定位桶的。这篇深入理解 Golang Map我觉得讲解的对。靠高8位来定位key是正确的，源码中就是靠高8位来计算的tophash，从而去找到key的位置。