散列表

散列表

   概要

   散列表也叫哈希表（hash table)，是存储Key-Value映射的集合。对于某一个Key，散列表可以在接近O(1)的时间内进行读写操作。 散列表在本质上也是一个数组，可以根据下标，进行元素的随机访问。

   散列表通过哈希函数实现Key和数组下标的转换，每个键值对都会通过哈希函数计算出一个索引，然后存储在对应的位置上。通过开放寻址法和链表法来解决哈希冲突 。

   下面这个table就是散列表：

   一、Java中的hashMap

   HashMap 是 Java 中的一种数据结构。它实际上是基于散列表（hash table）实现的。

   HashMap是一个用于存储Key-Value键值对的集合，每一个键值对也叫做Entry。这些个键值对（Entry）分散存储在一个数组当中，这个数组就是HashMap的主干。 数组中的每一个Entry元素，又是一个链表的头节点。

   HashMap数组每一个元素的初始值都是Null。

   1. 写操作（Put）

   写操作就是在散列表中插入新的键值对（在JDK中叫做Entry）

   1)  通过哈希函数来确定Entry的插入位置（index）

   2）如果该位置没有元素，就把这个Entry填充进去，但是，由于数组的长度是有限的，当插入的Entry越来越多时，不同的key通过哈希函数获得的下标可能是相同的。这种情况就叫做哈希冲突。

   解决哈希冲突的方法主要有两种：开放寻址法和链表法。在Java中，针对解决哈希冲突，ThreadLocal所使用的就是开放寻址法，HashMap中采用的链表法。

   链表法：HashMap数组的每一个元素不止是一个Entry对象，也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时，只需要插入到对应的链表即可，采用头插法（HashMap的发明者认为，后插入的Entry被查找的可能性更大。）

   2. 读操作（Get)

   1) 通过哈希函数，把key转化为对应的index

   2) 通过index找到对应的元素，由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。

   3. 扩容（Resize）

   既然散列表是基于数组实现的，那么散列表也要涉及扩容的问题。

   当经过多次元素插入，散列表达到一定饱和度时，key映射位置发生冲突的概率会逐渐提高。这样一来，大量元素拥挤在相同的数组下标位置，形成很长的链表，对后续插入操作和查询操作的性能都有很大影响。

   这时候，HashMap需要扩展它的长度，也就是进行Resize。

   1）影响扩容的两个因素
   Capacity：HashMap的当前长度
   LoadFactor：HashMap的负载因子，默认值为0.75f

   2）衡量HashMap需要进行Resize条件
   HashMap.Size >= Capacity * LoadFactor

   3）扩容步骤

   HashMap的Resize不是简单地把长度扩大，而是经过下面两个步骤：

   扩容（Resize）：创建一个新的Entry空数组，长度是原数组的2倍。

   重新Hash（ReHash）：遍历原Entry数组，把所有的Entry重新Hash到新数组中。为什么要重新Hash呢？因为长度扩大以后，Hash的规则也随之改变。

   说明： ReHash在并发的情况下可能会形成链表环，让下一次读操作出现死循环。

 

   结果：经过扩容，原本拥挤的散列表重新变得稀疏，原有的Entry也重新得到了尽可能均匀的分配。

   4.  HashMap默认的初始长度

   1)  初始长度

   默认初始长度是16，并且每次自动扩展或者手动初始化时，长度必须是2的幂

   原因：之所以选择16，是为了服务于从Key映射到index的hash算法。长度16或者其他2的幂，Length-1的值是所有二进制位全为1，这种情况下，index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀，Hash算法的结果就是均匀的。

   说明：如果长度不是2的幂，那么计算之后，有些index结果的出现几率会更大，而有些index结果永远不会出现。不符合Hash算法均匀分布的原则。

   2）哈希函数

   从Key映射到HashMap数组的对应位置，会用到一个Hash函数。如何实现一个尽量均匀分布的Hash函数呢？我们通过利用Key的HashCode值来做某种运算。如下：

   index = HashCode（Key） & （Length - 1）

   说明：取模运算的方式固然简单，但是效率很低。为了实现高效的Hash算法，HashMap的发明者采用了位运算的方式。

   5. 高并发下，为什么HashMap可能会出现死循环

   Hashmap不是线程安全的。在高并发环境下做插入操作，有可能出现下面的环形链表。

   

   当多个线程同时对HashMap进行插入、删除等操作时，可能会引发链表结构的变化。如果两个线程同时进行插入操作，且发生了哈希冲突，那么它们可能会同时修改链表的结构，例如添加一个新节点到链表头部。在这种情况下，如果另一个线程正在遍历这个链表，就可能导致遍历线程进入死循环，因为链表的结构在遍历过程中发生了变化。

   二. JDK1.7和JDK1.8中，HashMap和ConcurrentHashMap的实现有什么不同？

   1. HashMap   

   1）多线程操作导致死循环问题

   产生原因：JDK1.7 及之前版本的 HashMap 在多线程环境下扩容操作可能存在死循环问题，这是由于当一个桶位中有多个元素需要进行扩容时，多个线程同时对链表进行操作，头插法可能会导致链表中的节点指向错误的位置，从而形成一个环形链表，进而使得查询元素的操作陷入死循环无法结束。

   为了解决这个问题，JDK1.8 版本的 HashMap 采用了尾插法而不是头插法来避免链表倒置，使得插入的节点永远都是放在链表的末尾，避免了链表中的环形结构。但是还是不建议在多线程下使用 HashMap，因为多线程下使用 HashMap 还是会存在数据覆盖的问题。并发环境下，推荐使用 ConcurrentHashMap 。

    2）Hash冲突解决方法

   JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。

     2. ConcurrentHashMap

     1）底层数据结构

     JDK1.7 的 ConcurrentHashMap 底层采用 分段的数组 + 链表 实现，JDK1.8 采用的数据结构跟 HashMap1.8 的结构一样，数组+链表/红黑二叉树。

     2）线程安全实现方式

    JDK 1.7 采用 Segment 分段锁来保证安全， Segment 是继承自 ReentrantLock。JDK1.8 放弃了 Segment 分段锁的设计，采用 Node数组 + CAS + synchronized 保证线程安全，锁粒度更细，synchronized 只锁定当前链表或红黑二叉树的首节点

    说明：concurrentHashMap的详细介绍请参加文章《》

     3）并发度

    JDK 1.7 最大并发度是 Segment 的个数，默认是 16。JDK 1.8 最大并发度是 Node 数组的大小，并发度更大。

 

    参考资料：《程序员小灰》微信公众号