摘要:
「散列表」（Hash Table）或「Hash 表」是基于数组扩展的数据结构，能够将复杂信息通过「Hash 算法」生成「Hash 值」，以对应数组下标，完成快速随机访问数据的功能。
"我"从哪里来
我们已经知道随机访问数组元素时间复杂度只有 ，效率极高，当我们想利用数组的这个特性时就需要将元素下标与存储信息对应。例如，一个商店只有四件商品，依次编号 0 至 3，这样就可以将四件商品信息按照编号对应下标的方式存储到数组中，依据编号就可以快速从数组中找到相应商品信息。
如果一段时间之后，商店盈利并且重新进货 100 件商品，商家想对大量商品在编号上区分类别，这时候需要使用类别编号加顺序编号的方式标识每件商品，这种编号变得复杂，并不能直接对应数组下标，此时的商品编号又该如何对应数组下标以实现快速查找商品的功能？这时候我们可以将类别编号去除之后按照顺序编号对应数组下标，同样也能享受数组高效率随机访问的福利。这个例子中，商品编号称为「键」或「关键字」，将键转化为数组对应下标的方法就是「散列函数」或「Hash 函数」，由散列函数生成的值叫做「散列值」或「Hash 值」，而这样的数组就是散列表。
散列表的关键
从散列表的原理来看，数据通过散列函数计算得到散列值是关键，这个步骤中散列函数又是其中的核心，一个散列函数需要遵守以下三个原则。
- 生成的散列值是非负整数
- 如果 ，那么
- 如果 ，那么
因为散列函数生成的散列值对应数组下标，而数组下标就是非负整数，所以需要满足第一个原则；两个相等的数据经过散列算法得到的散列值肯定相等，否则利用散列值在散列表中查找数据就无从谈起；至于第三个原则虽然在情理之中，却不那么容易做到，即使是被广泛运用的散列算法也会出现散列值冲突的情况，导致无法满足第三个原则。
散列函数作为散列表的核心部分，必然不能拖散列表的执行效率后腿，毕竟散列表的查询、插入和删除操作都需要经过散列函数，所以散列函数不能太复杂，执行效率不能太低。由于散列函数不可避免地都会出现散列冲突情况，散列函数要尽量降低散列冲突，使散列值能够均匀地分布在散列表中。
如何解决散列冲突
解决散列冲突主要有「开放寻址」（open addressing）和「链表法」（chaining）两类方法。
开放寻址
开放寻址法是指插入操作时，当生成的散列值对应槽位已经被其他数据占用，就探测空闲位置供插入使用，其中探测方法又分为「线性探测」（Linear Probing）、「二次探测」（Quadratic Probing）和「双重散列」（Double hashing）三种。
三种探测方法
线性探测是其中较为简单的一种，这种探测方式是当遇到散列冲突的情况就顺序查找（查找到数组尾部时转向数组头部继续查找），直到查找到空槽将数据插入。当进行查找操作时，也是同样的操作，利用散列值从散列表中取出对应元素，与目标数据比对，如果不相等就继续顺序查找，直到查找到对应元素或遇到空槽为止，最坏情况下查找操作的时间复杂度可能会下降为 。
散列表除了支持插入和查找操作外，当然也支持删除操作，不过并不能将需删除的元素置为空。如果删除操作是将元素置为空的话，查找操作遇到空槽就会结束，存储在被删除元素之后的数据就可能无法正确查找到，这时的删除操作应该使用标记的方式，而不是使用将元素置空，当查找到被标识已删除的元素将继续查找，而不是就此停止。
线性探测是一次一个元素的探测，二次探测就是使用都是线性探测的二次方步长探测。例如线性探测是 ，那二次探测对应的就是 。
双重探测是当第一个散列函数冲突时使用第二个散列函数运算散列值，利用这种方式探测。例如，当 冲突时，就使用 计算散列值，如果再冲突就使用 计算散列值，依此类推。
动态扩容的困境
关于散列表的空位多少使用「装载因子」（load factor）表示，装载因子满足数学关系 ，也就是说装载因子越大，散列表的空闲空间越小，散列冲突的可能性也就越大，一般我们会保持散列表有一定比例的空闲空间。
为了保持散列表一定比例的空闲空间，在装载因子到达一定阈值时需要对散列表数据进行搬移，但散列表搬移比较耗时。你可以试想下这样的步骤，在申请一个新的更大的散列表空间后，需要将旧散列表的数据重新通过散列函数生成散列值，再存储到新散列表中，想想都觉得麻烦。
散列表搬移的操作肯定会降低散列表的操作效率，那能不能对这一过程进行改进？其实可以将低效的扩容操作分摊至插入操作，当装载因子达到阈值时不一次性进行散列表搬移，而是在每次插入操作时将一个旧散列表数据搬移至新散列表，这样搬移操作的执行效率得到了提高，插入操作的时间复杂度也依然能保持 的高效。当新旧两个散列表同时存在时查询操作就要略作修改，需先在新散列表中查询，如果没有查找到目标数据再到旧散列表中查找。
当然，如果你对内存有更高效的利用要求，可以在装载因子降低至某一阈值时对散列表进行缩容处理。
链表法
除了开放寻址之外，还可以使用链表法解决散列冲突的问题。散列值对应的槽位并不直接存储数据，而是将数据存储在槽位对应的链表上，当进行查找操作时，根据散列函数计算的散列值找到对应槽位，再在槽位对应的链表上查找对应数据。
链表法操作的时间复杂度与散列表槽位和数据在槽位上的分布情况有关，假设有 n 个数据均匀分布在 m 个槽位的散列表上，那链表法的时间复杂度为 。链表法可以不用像开放寻址一样关心装载因子，但需要注意散列函数对散列值的计算，使链表结点能够尽可能均匀地分布在散列表槽位上，避免散列表退化为链表。有时黑客甚至会精心制造数据，利用散列函数制造散列冲突，使数据集中某些槽位上，造成散列表性能的极度退化。
面对这样的恶意行为散列表只能坐以待毙吗？其实不然，当槽位上的链表过长时，可以将其改造成之前学习过的跳表等，链表改造为跳表后查询的时间复杂度也只是退化为 ，依然是可以接受的范围。
链表法在存储利用上比开放寻址更加高效，不用提前申请存储空间，当有新数据时申请一个新的结点就行。而且链表法对装载因子也不那么敏感，装载因子的增高也只是意味着槽位对应的链表更长而已，链表增长也有将链表改造为跳表等结构的应对策略，所以链表法在装载因子超过 1 的情况下都可保持高效。
开放寻址 VS 链表法
开放寻址不存在像链表法一样有链表过长而导致效率降低的烦恼，不过装载因子是开放寻址的晴雨表，装载因子过高会造成散列冲突机率的上升，开放寻址就需要不断探测空闲位置，算法的执行成本会不断被提高。而且在删除操作时只能将数据先标记为删除，对于频繁增删的数据效率会受到影响。
当然也可以在这种风险出现前进行散列表的动态扩容，不过这样就会出现大量空闲的存储空间，导致存储的利用效率过低，这种现象在数据量越大的情况下越明显。所以开放寻址比较适用于数据量较小的情况。
链表法对于散列冲突的处理更加灵活，同时对存储空间的利用效率也更高，但链表结点除了存储数据外还需要存储指针，如果存储数据较小指针占用的存储甚至会导致整体存储翻倍的情况，但存储数据较大时指针占用的存储也就可以忽略不计，所以链表法较适合存储数据对象较大，但频繁的增删操作不会对链表法造成明显的影响。因为这样的特点，链表法更加适合大数据量，或者数据对象较大的时候，如果数据操作频繁，那链表法更是不二之选。
总结
散列表由数组扩展而来，使用散列函数将键计算为散列值，散列值对应数据存储的数组下标。虽然散列表的执行效率较高，但会有散列冲突的问题，可以通过开放寻址法和链表法解决此问题。
开放寻址存储利用效率较低，适用数据量较小并且增删不频繁的情况，如果数据量较大，增删频繁的情况更加适用链表法，相对之下链表法更加普适。
文章中如有问题欢迎留言指正
数据结构与算法之美笔记系列将会做为我对王争老师此专栏的学习笔记，如想了解更多王争老师专栏的详情请到极客时间自行搜索。