(1)背景
(2)hash函数的好坏评价标准
(3)装载因子（元素个数）过大怎么办？
(4)解决hash冲突的方法
(4.1)拉链法
(4.2)开放地址法
(5)工业级散列表范例
-------
(1)背景
散列表的查询效率并不能笼统地说成是 O(1)。它跟散列函数、装载因子（元素个数）、散列冲突等都有关系。如果散列函数设计得不好，或者装载因子过高，都可能导致散列冲突发生的概率升高，查询效率下降。
在极端情况下，有些恶意的攻击者，还有可能通过精心构造的数据，使得所有的数据经过散列函数之后，都散列到同一个槽里。如果我们使用的是基于链表的冲突解决方法，那这个时候，散列表就会退化为链表，查询的时间复杂度就从 O(1) 急剧退化为 O(n)。
如果散列表中有 10 万个数据，退化后的散列表查询的效率就下降了 10 万倍。更直观点说，如果之前运行 100 次查询只需要 0.1 秒，那现在就需要 1 万秒。这样就有可能因为查询操作消耗大量 CPU 或者线程资源，导致系统无法响应其他请求，从而达到拒绝服务攻击（DoS）的目的。这也就是散列表碰撞攻击的基本原理。
如何设计一个可以应对各种异常情况的工业级散列表，来避免在散列冲突的情况下，散列表性能的急剧下降，并且能抵抗散列碰撞攻击？
(2)思路
要思考何为一个工业级的散列表？
(2.1)工业级的散列表的特性
1>支持快速的查询、插入、删除操作；
2>内存占用合理，不能浪费过多的内存空间；
3>性能稳定，极端情况下，散列表的性能也不会退化到无法接受的情况。
(2.2)设计思路：
1>设计一个合适的散列函数；
2>定义装载因子阈值，并且设计动态扩容策略；
3>选择合适的散列冲突解决方法。
(2.3)hash函数的好坏评价标准
1）计算速度快
散列函数的设计也不能太复杂，太复杂就会太耗时间，也会影响散列表的性能。
2）碰撞率低
具有较高的平衡性与低碰撞率；
3）计算结果随机且均匀分布
尽可能让散列后的值随机且均匀分布，这样会尽可能地减少散列冲突，即便冲突之后，分配到每个槽内的数据也比较均匀
(2.4)针对上面的散列表碰撞攻击的问题，现在想的解决方法为：
A> 尽量减少hash冲突；
即 hash值相同的情况尽量少发生；针对这种情况的解决方法就是动态扩容；
B>hash冲突时尽量快速的查找到目标；
针对该问题的解决方法就是拉链法时，使用红黑树或者跳表取代链表；
(3)装载因子（元素个数）过大怎么办？
(3.1)背景
装载因子越大，说明散列表中的元素越多，空闲位置越少，散列冲突的概率就越大。
不仅插入数据的过程要多次寻址或者拉很长的链，查找的过程也会因此变得很慢。
对于动态散列表来说，数据集合是频繁变动的，我们事先无法预估将要加入的数据个数，所以我们也无法事先申请一个足够大的散列表。随着数据慢慢加入，装载因子就会慢慢变大。当装载因子大到一定程度之后，散列冲突就会变得不可接受。
(3.2)解决方法
（3.2.1）动态扩容
当装载因子过大，超过某个阈值时，我们可以进行动态扩容；
重新申请一个更大的散列表，将数据搬移到这个新散列表中（即一次性扩容，为低效扩容）。因为散列表的大小变了，数据的存储位置也变了，所以我们需要通过散列函数重新计算每个数据的存储位置。
（3.2.1.1）如何避免低效地扩容？
1》背景
大部分情况下，动态扩容的散列表插入一个数据都很快，但是在特殊情况下，当装载因子已经到达阈值，需要先进行扩容，再插入数据，即一次性扩容。这个时候，插入数据就会变得很慢；
2》解决方法
分批扩容：
即将扩容操作穿插在插入操作的过程中，分批完成；
当有新数据要插入时，我们将新数据插入新散列表中，并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表，我们都重复上面的过程。经过多次插入操作之后，老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移，插入操作就都变得很快了。
分批扩容的查询：
对于查询操作，为了兼容了新、老散列表中的数据，我们先从新散列表中查找，如果没有找到，再去老的散列表中查找。
通过这样均摊的方法，将一次性扩容的代价，均摊到多次插入操作中，就避免了一次性扩容耗时过多的情况。这种实现方式，任何情况下，插入一个数据的时间复杂度都是 O(1)。
（3.2.2）动态缩容
对于动态散列表，随着数据的删除，散列表中的数据会越来越少，空闲空间会越来越多。如果我们对空间消耗非常敏感，我们可以在装载因子小于某个值之后，启动动态缩容。
当然，如果我们更加在意执行效率，能够容忍多消耗一点内存空间，那就可以不用缩容了。
（3.2.3）装载因子阈值的设置
当散列表的装载因子超过某个阈值时，就需要进行扩容。装载因子阈值需要选择得当。如果太大，会导致冲突过多；如果太小，会导致内存浪费严重。
装载因子阈值的设置要权衡时间、空间复杂度。如果内存空间不紧张，对执行效率要求很高，可以降低负载因子的阈值；相反，如果内存空间紧张，对执行效率要求又不高，可以增加负载因子的值。
(4)解决hash冲突的方法
(4.1)开放地址法(open address)
(4.1.3)定义
如果出现了散列冲突、我们就重新探测一个空闲位置、将其插入、那如何重新探测新的位置呢？
当某个数据经过散列函数散列滞后、存储位置已经被占用了；我们就从当前位置开始、依次往后查找，看是否有空闲位置，直到找到为止；
随机数法：就是有冲突了，按照随机数列表来找下一个位置，直到找到了下一个空闲位置为止；
(4.1.2)节点的查找
根据要查找的元素的key进行hash后得到hash表中的元素和要查找的元素的value是否相等；
1）相等则找到；
2）不相等且下一个位置非空时，一直往下找；
直到找到 或者下一个位置为空（存在delete标记也需要继续往下找），为空则表示不存在；
(4.1.3)节点的删除
不能单纯地把删除的元素设置为空，而是设置一个标记；
因为如果把删除的位置设置为空，在找到一个空闲位置，我们就可以认定散列表中不存在这个数据。但是，如果这个空闲位置是我们后来删除的，就会导致hash值相同但是处于删除节点的后续节点的查找都失效了。
可以将删除的元素、特殊标记为deleted，当线性探测的时候、遇到标记为deleted的空间、并不是停下来、而是继续往下探测；
(4.1.4)优点
1> 每个hash值最多只对应一个元素；
2> 数据都存储在数组中，可以有效地利用 CPU 缓存加快查询速度;
(4.1.5)缺点
1> 删除时，需要特殊标记已经删除；
2> 比起链表法来说, 冲突的代价更高;
所以，使用开放寻址法解决冲突的散列表，装载因子的上限不能太大。这也导致这种方法比链表法更浪费内存空间;
(4.1.6)应用
当数据量比较小、装载因子小的时候，适合采用开放寻址法;
(4.2)拉链法
(4.2.1)优点
1> 链表法对内存的利用率比开放寻址法要高;
2> 对大装载因子(元素个数多)的容忍度更高;
(4.2.2)缺点
1> 存储指针，对小存储对象而言，占用更多内存；
链表因为要存储指针，所以对于比较小的对象的存储，是比较消耗内存的，还有可能会让内存的消耗翻倍;
如果我们存储的是大对象，也就是说要存储的对象的大小远远大于一个指针的大小（4 个字节或者 8 个字节），那链表中指针的内存消耗在大对象面前就可以忽略了。
2> 链表对cpu缓存不友好；
链表中的结点是零散分布在内存中的，不是连续的，所以对 CPU 缓存是不友好的; 对于执行效率也有一定的影响;
(4.2.3)改进
将链表法中的链表改造为其他高效的动态数据结构，比如跳表、红黑树。这样，即便出现散列冲突，极端情况下，所有的数据都散列到同一个桶内，那最终退化成的散列表的查找时间也只不过是 O(logn)。
这样也就有效减轻了前面讲到的散列碰撞攻击。
(4.2.4)应用
基于链表的散列冲突处理方法比较适合存储大对象、大数据量的散列表，而且，比起开放寻址法，它更加灵活，支持更多的优化策略，比如用红黑树代替链表。
(5)工业级散列表范例
Java 中的 HashMap 这样一个工业级的散列表，来具体看下，这些技术是怎么应用的。
(5.1)初始大小
HashMap 默认的初始大小是 16，当然这个默认值是可以设置的，如果事先知道大概的数据量有多大，可以通过修改默认初始大小，减少动态扩容的次数，这样会大大提高 HashMap 的性能。
(5.2)装载因子和动态扩容
最大装载因子默认是 0.75，当 HashMap 中元素个数超过 0.75*capacity（capacity 表示散列表的容量）的时候，就会启动扩容，每次扩容都会扩容为原来的两倍大小。
注：散列表的装载因子 = 填入表中的元素个数 / 散列表的长度；
当前的装载因子越大，说明空闲位置越少，冲突越多，散列表的性能会下降；
(5.3)散列冲突解决方法
HashMap 底层采用链表法来解决冲突。即使负载因子和散列函数设计得再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响 HashMap 的性能。
于是，在 JDK1.8 版本中，为了对 HashMap 做进一步优化，我们引入了红黑树。而当链表长度太长（默认超过 8）时，链表就转换为红黑树。我们可以利用红黑树快速增删改查的特点，提高 HashMap 的性能。当红黑树结点个数少于 8 个的时候，又会将红黑树转化为链表。因为在数据量较小的情况下，红黑树要维护平衡，比起链表来，性能上的优势并不明显。
(5.4)散列函数
散列函数的设计并不复杂，追求的是简单高效、低碰撞率、分布均匀；
其中，hashCode() 返回的是 Java 对象的 hash code。
比如String类型的对象的hashCode()就是下面这样：
|
1 2 3 4 5 6 7 8 9 10 11 |
|
(6)散列表的应用
问题：
旦我们在Word里输入一个个错误的英文单词，它就会用标红的放式提示“拼写错误”。
Word的这个单词拼写检查功能，虽然很小但却非常实用。你有没有想过，这个功能是如何实现的呢？
分析：
常用的英语单词有20万个左右，假设单词的平均速度是10个字母，平均一个单词占用10个字节的内存空间，那20万英个单词大约占2MB的存储空间，就算放大10倍也就是20MB。
对于现在的计算机来说，这个现在完全可以放在内存里面。所以我们可以用散列表来存储整个英文单词词典。当用户输入某个英文单词时，我们拿用户输入的单词去散列表中查找。如果查到，则说明拼写正确；如果没有查到，则说明拼写可能有误，给予提示。
借助散列表这种数据结构，我们就可以轻松实现快速判断是否存在拼写错误。