为什么unordered_map桶的大小是8?

其实还是因为泊松分布。
哈希,又似里!
STL中的hashmap就是unordered_map。它记录的键是元素的哈希值,通过对比元素的哈希值来确定元素的值。unordered_map的底层实现是hashtable,采用开链法(也就是用桶)来解决哈希冲突,当桶的大小超过8时,就执行rehash操作(hashmap是转为rbtree)。那为什么这个数字是8呢?
官方给出这样一张表:

0: 0.60653066
1: 0.30326533
2: 0.07581633
3: 0.01263606
4: 0.00157952
5: 0.00015795
6: 0.00001316
7: 0.00000094
8: 0.00000006

即,在理想情况下,在随机哈希代码下,桶中的节点频率遵循泊松分布,而经过统计,桶的长度超过8的概率非常非常小,那7也不错,9也可以,为什么是8?这牵扯到哈希以位运算的扩容机制,当桶的大小为2的幂次方时,计算的效率最高,所以8是一个合理的选择。


然后我兴致冲冲的去看源码,在 /usr/include/c++/4.8.2/tr1/unordered_map:86,发现初始化的桶大小写死为 10 (黑人问号?)???

explicit
unordered_map(size_type n = 10,
      const hasher& hf = hasher(),
      const key_equal& eql = key_equal(),
      const allocator_type& a = allocator_type())
: Base(n, hf, Internal::mod_range_hashing(),
   Internal::default_ranged_hash(),
   eql, Internal::extract1st<std::pair<const Key, T> >(), a)
{ }

当然是10啦,因为10*0.8=8,当为8的时候扩容啊~

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值