HashMap原理解析-面试常用划重点

前言

数据结构几乎是面试的日常了,其中HashMap更是常客,很多人说到HashMap都能”画虎烂”两句,但是类似:

  • 高并发中HashMap为何会出现死锁?
  • Java8中,HashMap的结构有如何优化?

却有很多人吃了哑巴亏,这篇博文就在这个两个问题上展开,看看它背后的故事~!

HashMap简介

众所周知,HashMap是一个用于存储Key-Value键值对的集合,每一个键值对也叫做Entry。这些个键值对(Entry)分散存储在一个数组当中,这个数组就是HashMap的主干。

HashMap基本结构与原理

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

基础结构

对于HashMap,我们最常使用的是两个方法:Get 和 Put。

1.Put方法的原理

调用Put方法的时候发生了什么呢?

比如调用 hashMap.put("apple", 0) ,插入一个Key为“apple“的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置(index):

index = Hash(“apple”)

假定最后计算出的index2,那么结果如下:
基础结构演示1
但是,因为HashMap的长度是有限的,当插入的Entry越来越多时,再完美的Hash函数也难免会出现index冲突的情况。比如下面这样:
基础结构演示2
这时候该怎么办呢?我们可以利用链表来解决。
HashMap数组的每一个元素不止是一个Entry对象,也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时,只需要插入到对应的链表即可:
基础结构演示3
需要注意的是,新来的Entry节点插入链表时,使用的是“头插法”。至于为什么不插入链表尾部,后面会有解释。

2.Get方法的原理

使用Get方法根据Key来查找Value的时候,发生了什么呢?

首先会把输入的Key做一次Hash映射,得到对应的index:

index = Hash(“apple”)

由于刚才所说的Hash冲突,同一个位置有可能匹配到多个Entry,这时候就需要顺着对应链表头节点,一个一个向下来查找。假设我们要查找的Key是“apple”:
基础结构演示4

第一步,我们查看的是头节点Entry6Entry6Keybanana,显然不是我们要找的结果。

第二步,我们查看的是Next节点Entry1Entry1Keyapple,正是我们要找的结果。

之所以把Entry6放在头节点,是因为HashMap的发明者认为,后插入的Entry被查找的可能性更大。

深入HashMap,解析前言中的问题

首先明确一点,HashMap的默认长度是16,并且每次自动扩展或是手动初始化时,长度必须是2的幂.之所以选择16,是为了服务与Key映射到indexHash算法

之前说过,从Key映射到HashMap数组的对应位置,会用到一个Hash函数:

index = Hash(“apple”)

如何实现一个尽量均匀分布的Hash函数呢?我们通过利用KeyHashCode值来做某种运算。

以前的计算方式: index = HashCode(Key) % Length
现在的计算方式: index = HashCode(Key) & (Length - 1)

以前的取模运算的方式固然简单,但是效率很低。为了实现高效的Hash算法,HashMap的发明者采用了位运算的方式。
下面我们以值为“book”的Key来演示整个过程:

1.计算book的hashcode,结果为十进制的3029737,二进制的101110001110101110 1001。

2.假定HashMap长度是默认的16,计算Length-1的结果为十进制的15,二进制的1111。

3.把以上两个结果做与运算,101110001110101110 1001 & 1111 = 1001,十进制是9,所以 index=9。

可以说,Hash算法最终得到的index结果,完全取决于KeyHashcode值的最后几位。

这样做不但效果上等同于取模而且还大大提高了性能。至于为什么采用16,我们可以试试长度是10会出现什么问题.

假设HashMap的长度是10,重复刚才的运算步骤:
HashMap位运算演示1
单独看这个结果,表面上并没有问题。我们再来尝试一个新的HashCode 101110001110101110 1011
HashMap位运算演示2
让我们再换一个HashCode 101110001110101110 1111 试试:
HashMap位运算演示3
是的,虽然HashCode的倒数第二第三位从0变成了1,但是运算的结果都是1001。也就是说,当HashMap长度为10的时候,有些index结果的出现几率会更大,而有些index结果永远不会出现(比如0111)!

这样,显然不符合Hash算法均匀分布的原则。

反观长度16或者其他2的幂,Length-1的值是所有二进制位全为1,这种情况下,index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀,Hash算法的结果就是均匀的。


来说说死锁产生的原因!

通过上文咱们知道HashMap初始容量大小为16,一般来说,Hash表这个容器当有数据要插入时,都会检查容量有没有超过设定的thredhold,如果超过,需要增大Hash表的尺寸,但是这样一来,整个Hash表里的元素都需要被重算一遍。这叫rehash,这个成本相当的大。

HashMap非线程安全,死锁一般都是产生于并发情况下。我们假设有二个进程T1、T2,HashMap容量为2,T1线程放入key A、B、C、D、E。在T1线程中A、B、C Hash值相同,于是形成一个链接,假设为A->C->B,而D、E Hash值不同,于是容量不足,需要新建一个更大尺寸的Hash表,然后把数据从老的Hash表中
迁移到新的Hash表中(refresh)。这时T2进程闯进来了,T1暂时挂起,T2进程也准备放入新的key,这时也
发现容量不足,也refresh一把。refresh之后原来的链表结构假设为C->A,之后T1进程继续执行,链接结构
A->C,这时就形成A.next=B,B.next=A环形链表。一旦取值进入这个环形链表就会陷入死循环


那有什么替代的方案呢?

使用ConcurrentHashMap进行替代,ConcurrentHashMap是一个线程安全的HashTable。可能有人会使用HashTable。当然HashTable也是线程安全,但HashTable锁定的是整个Hash表,效率相对比较低。而ConcurrentHashMap可以做到读取数据不加锁,并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小。

文中阐述不妥之处还望雅正,不吝感激。

转载请注明出处:天雷

以上

谢谢你请我吃糖果