map 的设计也被称为 “The dictionary problem”，
它的任务是设计一种数据结构用来维护一个集合的数据，
并且可以同时对集合进行增删查改的操作。
map最主要的数据结构有两种：
哈希查找表（Hash table）
查找表用一个哈希函数将 key 分配到不同的桶（bucket，也就是数组的不同 index）
开销主要在哈希函数的计算以及数组的常数访问时间。在很多场景下，哈希查找表的性能很高。
哈希查找表最差是 O(N), 平均查找效率是 O(1)
遍历哈希查找表则是乱序的
解决冲突的办法: 链表法和开放地址法
搜索树（Search tree）
一般采用自平衡搜索树，包括：AVL 树，红黑树(c++)。
自平衡搜索树法的最差搜索效率是 O(logN)
遍历自平衡搜索树，返回的 key 序列，一般会按照从小到大的顺序注: Go 语言采用的是哈希查找表，并且使用链表解决哈希冲突。
hash函数，有加密型和非加密型。
加密型的一般用于加密数据、数字摘要等，典型代表就是md5、sha1、sha256、aes256这种；
非加密型的一般就是查找。在map的应用场景中，用的是查找。选择hash函数主要考察的是两点：性能、碰撞概率。
golang使用的hash算法根据硬件选择，如果cpu支持aes，那么使用aes hash，否则使用memhash，
//初始化: 最重要的肯定就是确定一开始要有多少个桶，初始化哈希种子等等
func makemap_small() *hmap {
h := new(hmap)
h.hash0 = fastrand()
return h
}
// makemap implements Go map creation for make(map[k]v, hint).
func makemap(t *maptype, hint int, h *hmap) *hmap {
.....
// initialize Hmap
if h == nil {
h = (*hmap)(newobject(t.hmap))
}
h.hash0 = fastrand()
// find size parameter which will hold the requested # of elements
B := uint8(0)
for overLoadFactor(hint, B) {
B++
}
h.B = B
......
return h
}
存储逻辑结构
map数据结构
// A header for a Go map.
type hmap struct {
count int // len()返回的map的大小 即有多少kv对
flags uint8
B uint8 // 表示hash table总共有2^B个buckets
hash0 uint32 // hash seed
buckets unsafe.Pointer // 按照low hash值可查找的连续分配的数组，初始时为16个Buckets. 当bucket(桶为0时)为nil
oldbuckets unsafe.Pointer
nevacuate uintptr
overflow *[2]*[]*bmap //溢出链 当初始buckets都满了之后会使用overflow
}// A bucket for a Go map.
type bmap struct {
tophash [bucketCnt]uint8
keys [8]keytype // 第二个是8个key、8个value
values [8]valuetype
pad uintptr
overflow uintptr // 第三个是溢出时，下一个溢出桶的地址
}
// 注意: key、value、overflow字段都不显示定义，而是通过maptype计算偏移获取的。
注:
之所以把所有k1k2放一起而不是k1v1是因为key和value的数据类型内存大小可能差距很大，
比如map[int64]int8，考虑到字节对齐，kv存在一起会浪费很多空间。
1. 计算出key的hash
2. 用最后的“B”位来确定在哪个桶（“B”就是前面说的那个，B为4，就有16个桶，0101用十进制表示为5，所以在5号桶）
3. 根据key的前8位快速确定是在哪个格子（额外说明一下，在bmap中存放了每个key对应的tophash，是key的前8位）
4. 最终还是需要比对key完整的hash是否匹配，如果匹配则获取对应value
5. 如果都没有找到，就去下一个overflow找
go/src/runtime/hashmap.go的mapassign函数
1. 通过key的后“B”位确定是哪一个桶
2. 通过key的前8位快速确定是否已经存在
3. 最终确定存放位置，如果8个格子已经满了，没地方放了，那么就重新创建一个bmap作为溢出桶连接在overflow
装载因子
如果你看过Java的HashMap实现，就知道有个装载因子，同样的在golang中也有，但是不一样哦。装载因子的定义是这个样子：
loadFactor := count / (2^B)
其中count为map中元素的个数，B就是之前个那个“B”
翻译一下就是装载因子 = （map中元素的个数）/（map当前桶的个数）扩容条件1
装载因子 > 6.5（这个值是源码中写的）
其实意思就是，桶只有那么几个，但是元素很多，证明有很多溢出桶的存在（可以想成链表拉的太长了），那么扫描速度会很慢，就要扩容。扩容条件2
overflow 的 bucket 数量过多：当 B 小于 15，如果 overflow 的 bucket 数量超过 2^B ；当 B >= 15，如果 overflow 的 bucket 数量超过 2^15 。
其实意思就是，可能有一个单独的一条链拉的很长，溢出桶太多了，说白了就是，加入的key不巧，后B位都一样，一直落在同一个桶里面，这个桶一直放，虽然装载因子不高，但是扫描速度就很慢。扩容条件3
当前不能正在扩容是否线程安全？否，而且并发操作会抛出异常。
源码位置：src/runtime/hashmap.go
每次遍历map顺序是否一致？不一致，每次遍历会随机个数，通过随机数来决定从哪个元素开始。原文：https://www.cnblogs.com/iiiiiher/p/12258510.html