标签：style http color ar os 使用 sp 数据 on
为提高hash表查找性能，除了考虑选择合适的hash表表长和完美的hash函数外，还必须考虑hash表处理冲突的能力。当hash函数对两个不同的数据项产生了相同的hash值时，冲突就产生了。对于冲突的处理，通常采用的方法可以分为三类：
（1）线性再散列法，简单的按顺序遍历hash表，寻找下一个可用的槽；
（2）非线性再散列法，计算一个新的hash值；
（3）外部拉链法，将hash表中的每个槽当作具有相同hash值的数据项所组成链表的头部，hash表将发生冲突的项添加到同一个链表中。
下面对这三种方法分别介绍。
线性再散列法是形式最简单的处理冲突的方法。插入元素时，如果发生冲突，算法会简单的遍历hash表，直到找到表中的下一个空槽，并将该元素 放入该槽中。查找元素时，首先散列值所指向的槽，如果没有找到匹配，则继续遍历hash表，直到：（1）找到相应的元素；（2）找到一个空槽（指示查找的 元素不存在）；（3）整个hash表遍历完毕（指示该元素不存在并且hash表是满的）。下表显示了以线性再散列法将｛89，18，49，58，69｝5 个元素插入hash表的过程。（hash函数为：hash(X)=X mod 10；hash表长一般用素数，这里为了说明方便取表长为10）
第一次冲突发生在插入关键字49时，它被放在下一个空闲地址，即地址0。关键字58依次和18，89，49发生冲突，试选三次之后才找到一个 空单元。对69的冲突用类似的方法处理。从以上过程可以看出，只要表中有空闲单元，总可以找到，但这里选择步长为1，将会在hash表中产生聚集，即：即 使hash表相对较空，还是会在某些区域形成一些区块，这些区块中的任何活动都将设计更大的步长。但如果以5或更大的值作为步长，可以迅速地从拥挤区域移 开，从而减少聚集现象的发生。事实上，只要hash表长和检查槽的步长是互质的，那么表中的每个槽都会被检查到。
线性再散列法有两个缺点：第一，不能从表中删除元素，因为相应的单元可能已经引起过冲突，元素绕过它存到了别处，例如，如果我们删除了18，那么其他的元素都会找不到。如果确实需要删除，可以采用懒惰删除的方法。第二，当表被填满时性能下降明显。
线性再散列法是从冲突位置开始，采用一个步长以顺序方式遍历hash表，来查找一个可用的槽，从上面的讨论可以看出，它容易产生聚集现象。非线性再散列法 可以避免遍历散列表，它会计算一个新的hash值，并通过它跳转到表中一个完全不同的部分。它的思想就是：通过跳转到表中不同的部分，从而避免相似值的聚 集，如果再散列函数跳转到的槽已经被占用了，则继续执行新一轮的再散列和跳转。
例如，还是上面的例子，如果再散列函数是hash(X)=R-(X mod R)，其中R为小于hash表长的素数，如果我们选择R＝7，则下表显示了插入与前面相同的关键字的结果。
第一个冲突发生在49被插入的时候， hash(49)=7-0=7，故49被插入到位置6。Hash(58)=7-2=5，于是58被插入到位置3。最后69产生冲突，从而被插入到距离为hash(69)=7-6=1的地方。
非线性再散列法也有不能从表中删除元素的缺点。
无论是使用线性再散列法还是非线性再散列法，只有在散列表不会接近填满的情况下，才能使用再散列。当散列表的负载因子增大时，再散列所花费的时间也会显著增加。通过以上讨论可以看出，再散列方法适用于表负载较低并且不太可能执行删除操作的情况。
外部拉链法是将hash表看作是一个链表数组，表中的每个槽要不为空，要不指向hash到该槽的表项的链表。可以通过把元素添加到链表中来解决冲突。同 样，可以通过从链表中删除元素来执行删除操作。因此，解决冲突的代价不会超过向链表中添加一个节点，不需要执行再散列。在再散列中，表项的最大数量是由表 中槽的原始数量确定的，与之不同的是，外部拉链法可以容纳的元素于将在内存中存放的元素一样多。
外部拉链法的原则是：hash表的大小一般与预料的元素个数差不多。
假设有一个表长为10的hash表，给出10个关键字为前10个自然数的平方，hash函数为hash(X)=X mod 10，下图就是对应的外部拉链法的hash表。
外部拉链法的平均查找时间是对链表的查找时间加上1，这个1是最初的定位hash表槽。外部拉链法的缺点是：它需要稍微多一些的空间来实现，因为添加任何元素都需要添加指向节点的指针，并且每次探查也要花费稍微多一点的时间，因为它需要间接引用指针，而不是直接访问元素。由于今天的内存成本很低并且可以使用非常快的CPU，所以这些缺点都是微不足道的。因此，实际使用hash表时，一般都是使用拉链法来解决hash冲突。
标签：style http color ar os 使用 sp 数据 on
原文地址：http://my.oschina.net/dyos/blog/342729
