散列表
散列表
概要
散列表也叫哈希表(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 数组的大小,并发度更大。
参考资料:《程序员小灰》微信公众号