散列表

Word文档中的单词拼写检查功能。

常用英文单词有20万个左右，假设单词的平均长度是10个字母，大约总共占2MB的存储空间，这个大小完全可以放在内存里面

散列表HashTable

散列表用的是数组支持按照下标随机访问数据的特性，所以散列表其实就是数组的一种扩展，由数组演化而来。可以说，如果没有数组，就没有散列表。

通过哈希函数将关键字映射为数组下标，从而实现O(1)的查找时间复杂度

散列冲突解决方法：开放地址法、链表法

线性探测:往散列表中插入数据时，如果某个数据经过散列函数散列之后，存储位置已经被占用了，我们就从当前位置开始，依次往后查找，看是否有空闲位置，直到找到为止。遍历到尾部都没有找到空闲位置，就再从表头开始找，直到找到空闲位置

二次探测

再哈希

装载因子：表示空位的多少，空位越少，冲突概率越高

链表法：插入时间复杂度O(1)

 

假设有10万条URL访问日志，如何按照访问次数给URL排序？

URL为key，访问次数为value，存入字典，然后桶排序/快速排序

有两个字符串数组，每个数组大约有10万条字符串，如何快速找出两个数组中相同的字符串？

以一个字符串构建散列表，key为字符串，value为次数，遍历另一个字符串，去散列表中查找

 

如何打造一个工业级的散列表？

散列函数的设计不能太复杂，散列函数生成的值要尽可能随机并且均匀分布

常用散列函数设计方法:

"数据分析法"；"求余取模"；"直接寻址法"；"平方取中法"；"折叠法";"随机数法"

装载因子过大了怎么办？-->动态扩容

装载因子越大说明散列表中的元素越多，空闲位置越少，散列冲突的概率就越大。不仅插入数据的过程要多次寻址或者拉很长的链，查找的过程也会因此变得很慢。

针对散列表，当装载因子过大时，我们也可以进行动态扩容，重新申请一个更大的散列表，将数据搬移到这个新散列表中。但是，针对散列表的扩容，数据搬移操作要复杂很多。因为散列表的大小变了，数据的存储位置也变了，所以我们需要通过散列函数重新计算每个数据的存储位置。

如何避免低效扩容？

为了解决一次性扩容耗时过多的情况，我们可以将扩容操作穿插在插入操作的过程中，分批完成。当装载因子触达阈值之后，我们只申请新空间，但并不将老的数据搬移到新散列表中。当有新数据要插入时，我们将新数据插入新散列表中，并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表，我们都重复上面的过程。经过多次插入操作之后，老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移，插入操作就都变得很快了。

如何选择冲突解决方法？

1.开放寻址法

散列表中的数据都存储在数组中，可以有效地利用 CPU 缓存加快查询速度。而且，这种方法实现的散列表，序列化起来比较简单。用开放寻址法解决冲突的散列表，删除数据的时候比较麻烦，需要特殊标记已经删除掉的数据。（Python中是dummy）而且，在开放寻址法中，所有的数据都存储在一个数组中，比起链表法来说，冲突的代价更高。所以，使用开放寻址法解决冲突的散列表，装载因子的上限不能太大。这也导致这种方法比链表法更浪费内存空间。

当数据量比较小、装载因子小的时候，适合采用开放寻址法。这也是 Java 中的ThreadLocalMap使用开放寻址法解决散列冲突的原因。

2.链表法

链表法对内存的利用率比开放寻址法要高。因为链表结点可以在需要的时候再创建，并不需要像开放寻址法那样事先申请好。链表法比起开放寻址法，对大装载因子的容忍度更高。开放寻址法只能适用装载因子小于 1 的情况。接近 1 时，就可能会有大量的散列冲突，导致大量的探测、再散列等，性能会下降很多。但是对于链表法来说，只要散列函数的值随机均匀，即便装载因子变成 10，也就是链表的长度变长了而已，虽然查找效率有所下降，但是比起顺序查找还是快很多。

链表因为要存储指针，所以对于比较小的对象的存储，是比较消耗内存的，还有可能会让内存的消耗翻倍。而且，因为链表中的结点是零散分布在内存中的，不是连续的，所以对 CPU 缓存是不友好的，这方面对于执行效率也有一定的影响。

对链表法稍加改造，可以实现一个更加高效的散列表。那就是，我们将链表法中的链表改造为其他高效的动态数据结构，比如跳表、红黑树。这样，即便出现散列冲突，极端情况下，所有的数据都散列到同一个桶内，那最终退化成的散列表的查找时间也只不过是 O(logn)。这样也就有效避免了前面讲到的散列碰撞攻击。

基于链表的散列冲突处理方法比较适合存储大对象、大数据量的散列表，而且，比起开放寻址法，它更加灵活，支持更多的优化策略，比如用红黑树代替链表。

 

工业级散列表举例分析/Java中的HashMap

1.初始大小：HashMap默认的初始大小是16，如果事先知道大概的数据量有多大，可以通过修改默认初始大小，减少动态扩容的次数，这样会大大提高HashMap的性能。

2.装载因子和动态扩容：最大装载因子默认是0.75，当HashMap中元素个数超过0.75*capacity的时候，就会启动扩容，每次扩容都会扩容为原来的两倍大小。

3.散列冲突解决方法：HashMap底层采用链表法来解决冲突。即使负载因子和散列函数设计的再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在 JDK1.8 版本中，为了对 HashMap 做进一步优化，我们引入了红黑树。而当链表长度太长（默认超过 8）时，链表就转换为红黑树。我们可以利用红黑树快速增删改查的特点，提高 HashMap 的性能。当红黑树结点个数少于 8 个的时候，又会将红黑树转化为链表。因为在数据量较小的情况下，红黑树要维护平衡，比起链表来，性能上的优势并不明显。

4.散列函数：散列函数的设计并不复杂，追求的是简单高效、分布均匀。

 

工业级的散列表应该具有哪些特性：

支持快速的查询、插入、删除操作

内存占用合理，不能浪费过多的内存空间

性能稳定，极端情况下，散列表的性能也不会退化到无法接受的情况

 

如何实现：

设计一个合适的散列函数-->要尽可能让散列后的值随机且均匀分布这样会尽可能地减少散列冲突，即便冲突之后，分配到每个槽内的数据也比较均匀。除此之外，散列函数的设计也不能太复杂，太复杂就会太耗时间，也会影响散列表的性能。

定义装载因子阈值，并且设计动态扩容策略 

选择合适的散列冲突解决方法

 

为什么散列表和链表会经常一起使用？

ＬＲＵ缓存淘汰算法 散列表+双向链表----------->需要维护一个按照访问时间从大到小有序排列的链表结构。因为缓存大小有限，当缓存空间不够，需要淘汰一个数据的时候，我们就直接将链表头部的节点删除。当缓存某个数据的时候，先在链表中查找这个数据，如果没有找到，则直接将数据放到链表的尾部；如果找到了，就把它移动到链表尾部。只用单链表的话查找时是O(n)的。

 

查找一个数据：散列表中查找数据的时间复杂度接近 O(1)，所以通过散列表，可以很快地在缓存中找到一个数据。当找到数据之后，还需要将它移动到双向链表的尾部。

删除一个数据：需要找到数据所在的结点，然后将结点删除。借助散列表，可以在 O(1) 时间复杂度里找到要删除的结点。因为链表是双向链表，双向链表可以通过前驱指针 O(1) 时间复杂度获取前驱结点，所以在双向链表中，删除结点只需要 O(1) 的时间复杂度。

添加一个数据：添加数据到缓存稍微有点麻烦，需要先看这个数据是否已经在缓存中。如果已经在其中，需要将其移动到双向链表的尾部；如果不在其中，还要看缓存有没有满。如果满了，则将双向链表头部的结点删除，然后再将数据放到链表的尾部；如果没有满，就直接将数据放到链表的尾部。

 

Redis的有序集合 跳表+散列表

在有序集合中，每个成员对象有两个重要的属性，key（键值）和 score（分值）。我们不仅会通过 score 来查找数据，还会通过 key 来查找数据。

 

Java LinkedHashMap

通过散列表和链表组合在一起实现的。不仅支持按照插入顺序遍历数据，还支持按照访问顺序来遍历数据。