hash表实际上由size个的桶组成一个桶数组table[0...size-1] 。

当一个对象经过哈希之后。得到一个对应的value , 于是我们把这个对象放到桶table[ value ]中。当一个桶中有多个对象时。我们把桶中的对象组织成为一个链表。

这在冲突处理上称之为拉链法。

负载因子（load factor）

如果一个hash表中桶的个数为 size , 存储的元素个数为used .则我们称 used / size 为负载因子loadFactor . 一般的情况下，当loadFactor<=1时，hash表查找的期望复杂度为O(1). 因此。每次往hash表中加入元素时。我们必须保证是在loadFactor <1的情况下，才可以加入。

容量扩张（Expand）& 分摊转移

当我们加入一个新元素时。一旦loadFactor大于等于1了，我们不能单纯的往hash表里边加入元素。

由于加入完之后，loadFactor将大于1，这样也就不能保证查找的期望时间复杂度为常数级了。这时。我们应该对桶数组进行一次容量扩张，让size增大 。

这样就能保证加入元素后 used / size 仍然小于等于1 ， 从而保证查找的期望时间复杂度为O(1).可是。怎样进行容量扩张呢？ C++中的vector的容量扩张是一种好方法。

于是有了例如以下思路 ：　Hash表中每次发现loadFactor==1时，就开辟一个原来桶数组的两倍空间（称为新桶数组），然后把原来的桶数组中元素所有转移过来到新的桶数组中。注意这里转移是须要元素一个个又一次哈希到新桶中的。原因后面会讲到。

这样的方法的缺点是，容量扩张是一次完毕的，期间要花非常长时间一次转移hash表中的全部元素。这样在hash表中loadFactor==1时。往里边插入一个元素将会等候非常长的时间。

redis中的dict.c中的设计思路是用两个hash表来进行进行扩容和转移的工作：当从第一个hash表的loadFactor=1时，假设要往字典里插入一个元素。首先为第二个hash表开辟2倍第一个hash表的容量。同一时候将第一个hash表的一个非空桶中元素所有转移到第二个hash表中。然后把待插入元素存储到第二个hash表里。继续往字典里插入第二个元素，又会将第一个hash表的一个非空桶中元素所有转移到第二个hash表中，然后把元素存储到第二个hash表里……直到第一个hash表为空。

这样的策略就把第一个hash表全部元素的转移分摊为多次转移，并且每次转移的期望时间复杂度为O(1)。

这样就不会出现某一次往字典中插入元素要等候非常长时间的情况了。

为了更深入的理解这个过程。先看看在dict.h中的两个结构体：

dictht指的就是上面说的桶数组，size用来表示容量，一般为2^n ，sizemask（一般为2^n-1,二进制表示为n个1）用来对哈希值取模 , used表示hash表中存储了多少个元素。

dict表示字典，由两个桶数组组成。type是一些函数指针（哈希函数及key。value的一些处理函数）。

d->rehashidx

这个变量的理解非常关键：

d->rehashidx 表明了新元素究竟是存储到桶数组0中。还是桶数组1中，同一时候指明了d->h[0]中究竟是哪一个桶转移到d->h[1]中。

当d->rehashidx==-1时，这时新加入的元素应该存储在桶数组0里边。

当d->rehashidx!=-1 时，表示应该将桶数组0中的第一个非空桶元素所有转移到桶数组1中来(最好还是称这个过程为桶转移，或者称为rehash)。这个过程必须将非空桶中的元素一个个又一次哈希放到桶数组1中，由于d->h[1]->sizemask已经不同于d->h[0]->sizemask了。

这时新加入的元素应该存储在桶数组1里边，由于此刻的桶数组0的loadFactor为1 。而桶数组1的loadFactor小于1 。

当发现桶数组0中的元素所有都转移到桶数组1中，即桶数组0为空时。释放桶数组0的空间。把桶数组0的指针指向桶数组1。将d->rehashidx赋值为-1 ，这样桶数组1就空了，下次加入元素时。仍然加入到桶数组0中。直到桶数组0的元素个数超过桶的个数，我们又又一次开辟桶数组0的2倍空间给桶数组1 ，同一时候改动d->rehashidx=0。这样下次加入元素是就加入到桶数组1中去了。

值得注意的是。在每次删除、查找、替换操作进行之前，依据d->rehashidx的状态来推断是否须要进行桶转移。这能够加快转移速度。

以下是一份精简的伪代码，通过依次插入element[1..n]这n个元素到dict来具体描写叙述容量扩张及转移的过程：

字典的迭代器（Iterator）

分为安全迭代器( safe Iterator )和非安全迭代器。

安全迭代器可以保证在迭代器未释放之前，字典两个hash表之间不会进行桶转移。

桶转移对迭代器的影响是很大的，如果一个迭代器指向d->h[0]的某个桶中的元素实体。在一次桶转移后，这个实体被rehash到d->h[1]中。

而在d->h[1]中根本不知道哪些元素被迭代器放过过，哪些没有被訪问过，这样有可能让迭代器反复訪问或者缺失訪问字典中的一些元素。

所以安全迭代器可以保证不多不少不反复的訪问到全部的元素（当然在迭代过程中。不能涉及插入新元素和删除新元素的操作）。

本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5245064.html，如需转载请自行联系原作者