Go Runtime hashmap实现
努力学习go中,看到skoo博客内容很不错, 所以转载学习下
前两天有小伙伴问道是否看过 Go 语言 map 的实现,当时还真没看过,于是就花了一点时间看了一遍 runtime 源码中的 hashmap 实现。map 的底层实现就是一个 hash 表,大体结构上和平时在脑海里的 hash 表差不多,但确实有很多细节(“Devils in the details”)。
![](http://skoo.me/assets/images/hashmap.png)
hashmap 通过一个 bucket 数组实现,所有元素将被 hash 到数组中的 bucket 中,bucket 填满后,将通过一个 overflow 指针来扩展一个 bucket 出来形成链表,也就是解决冲突问题。这也就是一个基本的 hash 表结构,没什么新奇的东西,下面总结一些细节吧。
- 注意一个 bucket 并不是只能存储一个 key/value 对,而是可以存储8个 key/value 对。每个 bucket 由 header 和 data 两部分组成,data 部分的内存大小为:(sizeof(key) + sizeof(value)) * 8,也就是要存储8对 key/value,这8对 key/value 在 data 内存中的存储顺序是:key0key1…key7value0value1…value7,是按照顺序先依次存储8个 key 值,然后存储对应的8个 value。 为什么不是存储为 key0value0…key7value7 呢?主要是方便访问吧。
- 如果 key, value 的类型大小超过了128字节,将不会直接存储值,而是存储其指针。
- bucket 的 header 部分有一个
uint8 tophash[8]
数组,这个数组将用来存储8个 key 的 hash 值的高8位值。比如:tophash[0] 存储的值就是 hash(key0) » (64 - 8)。保存了一个 key 的 hash 高8位部分,在查找/删除/插入一个 key 的时候,可以先判断两个 key hash 的高8位是否相等,如果不等,那就根本不用去比较 key 的内容。所以这里保存一下 hash 值的高8位可以作为第一步的粗略过滤,不少时候可以省掉比较两个 key 的内容,因为比较两个 key 是否相等的代价远比两个 uint8 的代价高。当然,这里如果存储整个 hash 值,而不仅仅是高8位的话,判断效果将更好,但内存的占用就会多很多了。 - bucket 的8个 key/value 空间如果都填满后,就会分配新的 bucket,通过 overflow 指针串联起来。注意这个链表指针被命名为 overflow,代表的正是 bucket 溢出了,这个命名感觉很好,hash 表实现的时候我们应该努力避免 bucket overflow。
- hashmap 是会自增长的,也就说随着插入的 kv 对越来越多,初始的 bucket 数组就可以需要增长、重新hash 所有元素,性能才会好。bucket 数组增长的时机就是插入的元素个数大于了
bucket数组大小 * 6.5
,为什么是6.5,这个在代码注释里有说明,主要是测试出来的经验值。 - hashmap 每次增长,都是重新分配一个新的 bucket 数组,新 bucket 数组是之前 bucket 数组的2倍大小。
- hashmap 增长后,需要将老 bucket 数组中的元素拷贝到新的 bucket 数组,这个拷贝过程不是一口气立马完成的,而是采用了增量式的拷贝,也就是说分配了新的 bucket 数组后,并没有立刻拷贝元素,而是等接下来每次插入一个元素的时候,才拷贝一点,随着插入的动作增多,逐渐就将全部元素拷贝到了新的 bucket 数组中。
- 在 make 一个 map 对象的时候,如果不指定大小的话,bucket 数组默认就是1了,随着插入的元素增多,就会增长成2,4,8,16等。可以看出不指定初始化大小的map,很可能要经历很多次的增长、元素拷贝。我们应该给 map 指定一个合适的大小值。
原文:http://skoo.me/go/2014/06/07/go-map