其实还是因为泊松分布。
哈希，又似里！
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的时候扩容啊~