散列表（Word文档中的单词拼写检查功能）

优势

  • 模拟映射关系
  • 防止重复
  • 缓存、记住数据，以免服务器再通过处理生成。
  • 查找、插入、删除都非常快。
  • 可以结合散列函数和数组来创建散列表，一般编程语言都提供了实现。

散列表执行各种操作的时间都为O(1)，常量时间，无论散列表多大，所需时间都相同。
平均情况下，查找与数组一样快，插入和删除速度与链表一样快。
填装因子： = 散列表占用位置 / 位置总数
填装因子越大，说明空闲位置越少，冲突越多，性能会下降。
一个小的经验规则：一旦填装因子大于0.7，就调整散列表的长度。
一个好的散列函数：SHA。

思想

数组支持按照下标随机访问数据的特性，散列表是数组的一种扩展，由数组演化而来。

散列冲突

  • 开放寻址法
    出现了冲突就重新探测一个空闲位置插入。
    比如线性检测：
    查找的过程中，遍历到空闲位置结束。
    删除的时候一般不是置空，而是标记为delete，因为置空会影响线性探测。
    二次探测：二次探测和线性探测相比，探测的步长为2。
    双重散列：不仅仅使用一个散列函数，如果第一个散列函数冲突，就使用第二个散列函数，依次类推。
  • 链表法
    每个元素位置再接一个链表。那个元素位置叫做桶或槽。多增加了链表的遍历。
    时间复杂度和链表的长度成正比。散列比较均匀的话，k = n/m，n = 数据个数，m是槽的个数。

词典检查就是把所有单词存储在散列表中进行查找，验证是否能找到。空间不大，放在内存里就行。

工业级散列表设计

动态扩容，均摊扩容（插入到新的散列表中，同时把老的散列表中一个数据拿到新的里面。）

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

虽然链表法比较耗费空间，但是如果存储的是大对象，那么链表中的结点占用空间很少，所以可以忽略不计。
比较适合存储大对象，大数据量的散列表，可以用红黑树代替链表。

HashMap 分析

默认是初始大小是16，可以调节。
最大装载因子是0.75，启动扩容会扩大到两倍大小。

底层使用链表法解决冲突，JDK1.8版本中，链表长度超过8时，链表转化为红黑树。当红黑树结点少于8个的时候，红黑树转化为链表。

以下为其散列函数。

int hash(Object key) {
    int h = key.hashCode()；//返回Java对象的hash code
    return (h ^ (h >>> 16)) & (capitity -1); //capicity 表示散列表的大小
}

散列表和链表的结合

将添加、删除、查找操作时间复杂度降到O(1)。
散列表中嵌入双向链表，双向链表增加特殊字段hnext。
结点除了可以使用前驱后继指针访问之外，还可以通过hnext索引访问（拉链）。
疑惑点：为何查找到一个结点之后将其放在链表尾部。

Redis有序集合
Redis和跳表关系很紧密

Java LinkedHashMap
LinkedHashMap可以支持按照插入顺序遍历数据，还支持按照访问顺序来遍历数据。
Linked指的是双向链表。
访问完数据之后也会放到链表结尾，估计是LRU策略（最近最少使用）

小结

散列表无法按照某种顺序快速遍历，一个方法是拷贝到数组中，排序遍历。
散列表是动态数据结构，不停有插入、删除情况。如果按照顺序遍历散列表，那么常常会将散列表和链表（或者跳表）一块使用。