散列表（哈希表）及其存储结构和特点详解_散列存储结构

顺序存储的结构类型需要一个一个地按顺序访问元素，当这个总量很大且我们所要访问的元素比较靠后时，性能就会很低。散列表是一种空间换时间的存储结构，是在算法中提升效率的一种比较常用的方式，但是所需空间太大也会让人头疼，所以通常需要在二者之间权衡。我们会在之后的具体算法章节中得到更多的领悟。

什么是散列表

让我们想一下，若在手机通信录中查找一个人，那我们应该不会从第 1 个人一直找下去，因为这样实在是太慢了。我们其实是这样做的：首先看这个人的名字的首字母是什么，比如姓张，那么我们一定会滑到最后，因为“Z”姓的名字都在最后。

还有在查字典时，要查找一个单词，肯定不会从头翻到尾，而是首先通过这个单词的首字母，找到对应的那一页；再找第 2 个字母、第 3 个字母……这样可以快速跳到那个单词所在的页。

其实这里就用到了散列表的思想。

散列表，又叫哈希表（Hash Table），是能够通过给定的关键字的值直接访问到具体对应的值的一个数据结构。也就是说，把关键字映射到一个表中的位置来直接访问记录，以加快访问速度。一种散列存储结构，通过关键字快速定位。

通常，我们把这个关键字称为 Key，把对应的记录称为 Value，所以也可以说是通过 Key 访问一个映射表来得到 Value 的地址。而这个映射表，也叫作散列函数或者哈希函数，存放记录的数组叫作散列表。

其中有个特殊情况，就是通过不同的 Key，可能访问到同一个地址，这种现象叫作碰撞（Collision）。而通过某个 Key 一定会得到唯一的 Value 地址。

目前，这个哈希函数比较常用的实现方法比较多，通常需要考虑几个因素：关键字的长度、哈希表的大小、关键字的分布情况、记录的查找频率，等等。

下面简单介绍几种哈希函数。

• 直接寻址法：取关键字或关键字的某个线性函数值为散列地址。
• 数字分析法：通过对数据的分析，发现数据中冲突较少的部分，并构造散列地址。例如同学们的学号，通常同一届学生的学号，其中前面的部分差别不太大，所以用后面的部分来构造散列地址。
• 平方取中法：当无法确定关键字里哪几位的分布相对比较均匀时，可以先求出关键字的平方值，然后按需要取平方值的中间几位作为散列地址。这是因为：计算平方之后的中间几位和关键字中的每一位都相关，所以不同的关键字会以较高的概率产生不同的散列地址。
• 取随机数法：使用一个随机函数，取关键字的随机值作为散列地址，这种方式通常用于关键字长度不同的场合。
• 除留取余法：取关键字被某个不大于散列表的表长 n 的数 m 除后所得的余数 p 为散列地址。这种方式也可以在用过其他方法后再使用。该函数对 m 的选择很重要，一般取素数或者直接用 n。

对散列表函数产生冲突的解决办法

散列表为什么会产生冲突呢？前面提到过，有时不同的 Key 通过哈希函数可能会得到相同的地址，这在我们操作时可能会对数据造成覆盖、丢失。之所以产生冲突是由于哈希函数有时对不同的 Key 计算之后获得了相同的地址。冲突的处理方式也有很多，下面介绍几种。

• 开放地址法（也叫开放寻址法）：实际上就是当需要存储值时，对Key哈希之后，发现这个地址已经有值了，这时该怎么办？不能放在这个地址，不然之前的映射会被覆盖。这时对计算出来的地址进行一个探测再哈希，比如往后移动一个地址，如果没人占用，就用这个地址。如果超过最大长度，则可以对总长度取余。这里移动的地址是产生冲突时的增列序量。
• 再哈希法：在产生冲突之后，使用关键字的其他部分继续计算地址，如果还是有冲突，则继续使用其他部分再计算地址。这种方式的缺点是时间增加了。
• 链地址法：链地址法其实就是对Key通过哈希之后落在同一个地址上的值，做一个链表。其实在很多高级语言的实现当中，也是使用这种方式处理冲突的，比如currenthashmap。
• 建立一个公共溢出区：这种方式是建立一个公共溢出区，当地址存在冲突时，把新的地址放在公共溢出区里。

散列表的存储结构

一个好的散列表设计，除了需要选择一个性能较好的哈希函数，否则冲突是无法避免的，所以通常还需要有一个好的冲突处理方式。这里我们选择除留取余法作为哈希函数，选择链地址法作为冲突处理方式。

具体存储结构如图 1 所示。

图 1 散列表的存储结构

散列表的特点

散列表有两种用法：一种是 Key 的值与 Value 的值一样，一般我们称这种情况的结构为 Set（集合）；而如果 Key 和 Value 所对应的内容不一样时，那么我们称这种情况为 Map，也就是键值对集合。

根据散列表的存储结构，我们可以得出散列表的以下特点。

1) 访问速度很快(数组的访问特点)

由于散列表有散列函数，可以将指定的 Key 都映射到一个地址上，所以在访问一个 Key（键）对应的 Value（值）时，根本不需要一个一个地进行查找，可以直接跳到那个地址。所以我们在对散列表进行添加、删除、修改、查找等任何操作时，速度都很快。

2) 需要额外的空间

首先，散列表实际上是存不满的，如果一个散列表刚好能够存满，那么肯定是个巧合。而且当散列表中元素的使用率越来越高时，性能会下降，所以一般会选择扩容来解决这个问题。另外，如果有冲突的话，则也是需要额外的空间去存储的，比如链地址法，不但需要额外的空间，甚至需要使用其他数据结构。

这个特点有个很常用的词可以表达，叫作“空间换时间”，在大多数时候，对于算法的实现，为了能够有更好的性能，往往会考虑牺牲些空间，让算法能够更快些。

3) 无序

散列表还有一个非常明显的特点，那就是无序。为了能够更快地访问元素，散列表是根据散列函数直接找到存储地址的，这样我们的访问速度就能够更快，但是对于有序访问却没有办法应对。

4) 可能会产生碰撞

没有完美的散列函数，无论如何总会产生冲突，这时就需要采用冲突解决方案，这也使散列表更加复杂。通常在不同的高级语言的实现中，对于冲突的解决方案不一定一样。

散列表的适用场景

根据散列表的特点可以想到，散列表比较适合无序、需要快速访问的情况。

缓存

通常我们开发程序时，对一些常用的信息会做缓存，用的就是散列表，比如我们要缓存用户的信息，一般用户的信息都会有唯一标识的字段，比如 ID。这时做缓存，可以把 ID 作为 Key，而 Value 用来存储用户的详细信息，这里的 Value 通常是一个对象（高级语言中的术语，前面提到过），包含用户的一些关键字段，比如名字、年龄等。

在我们每次需要获取一个用户的信息时，就不用与数据库这类的本地磁盘存储交互了（其实在大多数时候，数据库可能与我们的服务不在一台机器上，还会有相应的网络性能损耗），可以直接从内存中得到结果。这样不仅能够快速获取数据，也能够减轻数据库的压力。

有时我们要查询一些数据，这些数据与其他数据是有关联的，如果我们进行数据库的关联查询，那么效率会非常低，这时可以分为两部分进行查询：将被关联的部分放入散列表中，只需要遍历一遍；对于另一部分数据，则通过程序手动关联，速度会很快，并且由于我们是通过散列表的 Key、Value 的对应关系对应数据的，所以性能也会比较好。

快速查找

这里说的查找，不是排序，而是在集合中找出是否存在指定的元素。

这样的场景很多，比如我们要在指定的用户列表中查找是否存在指定的用户，这时就可以使用散列表了。在这个场景下使用的散列表其实是在上面提到的 Set 类型，实际上不需要 Value 这个值。

还有一个场景，我们一般对网站的操作会有个IP地址黑名单，我们认为某些 IP 有大量的非法操作，于是封锁了这些 IP 对我们网站的访问。这个 IP 是如何存储的呢？就是用的散列表。当一个访问行为发送过来时，我们会获取其 IP，判断其是否存在于黑名单中，如果存在，则禁止其访问。这种情况也是使用的 Set。