HashMap源码解析:深入理解Java集合框架

1 概述

HashMap是基于哈希表实现的,每一个元素是一个key-value对,其内部通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动增长.

HashMap是非线程安全的,只适用于单线程环境,多线程环境可以采用并发包下的concurrentHashMap

HashMap 实现了Serializable接口,因此它支持序列化,实现了Cloneable接口,能被克隆

HashMap是基于哈希表的Map接口的非同步实现.此实现提供所有可选的映射操作,并允许使用null值和null键.此类不保证映射的顺序,特别是它不保证该顺序恒久不变.

Java8中又对此类底层实现进行了优化,比如引入了红黑树的结构以解决哈希碰撞

2 HashMap的数据结构

在Java中,最基本的结构就是两种,一个是数组,另外一个是模拟指针(引用),所有的数据结构都可以用这两个基本结构来构造,HashMap也不例外.
HashMap实际上是一个"链表散列"的数据结构,即数组和链表的结合体.

ffe5067df505a886135677d4d1f078ca.jpeg

HashMap的主结构类似于一个数组,添加值时通过key确定储存位置.

每个位置是一个Entry的数据结构,该结构可组成链表.

当发生冲突时,相同hash值的键值对会组成链表.

这种数组+链表的组合形式大部分情况下都能有不错的性能效果,Java6、7就是这样设计的.

然而,在极端情况下,一组(比如经过精心设计的)键值对都发生了冲突,这时的哈希结构就会退化成一个链表,使HashMap性能急剧下降.

所以在Java8中,HashMap的结构实现变为数组+链表+红黑树

7724adb15c451ec1ee3a70b130e69a17.jpeg

可以看出,HashMap底层就是一个数组结构
数组中的每一项又是一个链表
当新建一个HashMap时,就会初始化一个数组.

3 三大集合与迭代子

HashMap使用三大集合和三种迭代子来轮询其Key、Value和Entry对象

b143d571d7c6ff5212e70c992dc0b613.jpeg

4 源码分析

aea0d20b16aeee717c3318e9f66351f9.jpeg

因为红黑树的平均查找长度是log(n),长度为8的时候,平均查找长度为3,如果继续使用链表,平均查找长度为8/2=4,这才有转换为树的必要

链表长度如果是小于等于6,6/2=3,虽然速度也很快的,但是转化为树结构和生成树的时间并不会太短

还有选择6和8,中间有个差值7可以有效防止链表和树频繁转换

假设一下,如果设计成链表个数超过8则链表转换成树结构,链表个数小于8则树结构转换成链表,如果一个HashMap不停的插入、删除元素,链表个数在8左右徘徊,就会频繁的发生树转链表、链表转树,效率会很低。

  • 44f795212338e6631954a10455483485.jpeg

    9639f21b4d9293466e9206b7f0a10430.jpeg

    上面的tableSizeFor有何用?
    tableSizeFor方法保证函数返回值是大于等于给定参数initialCapacity最小的2的幂次方的数值

06982917d5c2cf4d627ab38a24c6b712.jpeg

可以看出该方法是一系列的二进制位操作

a |= b 等同于 a = a|b

逐行分析

  • int n = cap - 1

给定的cap 减 1,为了避免参数cap本来就是2的幂次方,这样一来,经过后续操作,cap将会变成2 * cap,是不符合我们预期的

  • n |= n >>> 1

n >>> 1 : n无符号右移1位,即n二进制最高位的1右移一位

n | (n >>> 1) 导致 n二进制的高2位值为1

目前n的高1~2位均为1

  • n |= n >>> 2

n继续无符号右移2位

n | (n >>> 2) 导致n二进制表示的高3~4位经过运算值均为1

目前n的高1~4位均为1

  • n |= n >>> 4

n继续无符号右移4位

n | (n >>> 4) 导致n二进制表示的高5~8位经过运算值均为1

目前n的高1~8位均为1

  • n |= n >>> 8

n继续无符号右移8位

n | (n >>> 8) 导致n二进制表示的高9~16位经过运算值均为1

目前n的高1~16位均为1

可以看出,无论给定cap(cap < MAXIMUM_CAPACITY )的值是多少,经过以上运算,其值的二进制所有位都会是1.再将其加1,这时候这个值一定是2的幂次方.
当然如果经过运算值大于MAXIMUM_CAPACITY,直接选用MAXIMUM_CAPACITY.

dc9ca103234a32c7821b038a546e7896.jpeg

至此tableSizeFor如何保证cap为2的幂次方已经显而易见了,那么问题来了

4.1为什么cap要保持为2的幂次方?

主要与HashMap中的数据存储有关.

在Java8中,HashMap中key的Hash值由Hash(key)方法计得

c1a6559e7b3adb24c174caff6e0f0692.jpeg

HashMap中存储数据table的index是由key的Hash值决定的.

在HashMap存储数据时,我们期望数据能均匀分布,以防止哈希冲突.

自然而然我们就会想到去用%取余操作来实现我们这一构想

取余(%)操作 : 如果除数是2的幂次则等价于与其除数减一的与(&)操作.

这也就解释了为什么一定要求cap要为2的幂次方.再来看看table的index的计算规则:

这也就解释了为什么一定要求cap要为2的幂次方.再来看看table的index的计算规则:

bae9b276cf5efd61e8cdfe0e08f07dd7.jpeg

等价于:

index = e.hash % newCap

采用二进制位操作&,相对于%,能够提高运算效率,这就是cap的值被要求为2幂次的原因

0df84cbb918cbbcef1a3a9278027a9ce.jpeg acbc4785e63f11429994241cbf795173.jpeg

4.2 hash方法

Java 8中的散列值优化函数

f69408686832148a6dae7288b726843e.jpeg

只做一次16位右位移异或

key.hashCode()函数调用的是key键值类型自带的哈希函数,返回int型散列值

理论上散列值是一个int型,如果直接拿散列值作为下标访问HashMap主数组的话,考虑到2进制32位带符号的int范围大概40亿的映射空间。只要哈希函数映射得比较均匀松散,一般应用是很难出现碰撞的。

但问题是一个40亿长度的数组,内存是放不下的.HashMap扩容之前的数组初始大小才16,所以这个散列值是不能直接拿来用的.

用之前还要先做对数组的长度取模运算,得到的余数才能用来访问数组下标

源码中模运算就是把散列值和数组长度做一个"与"操作

7f36347cb5eb4eba9c22f9c4bd8f3207.jpeg

这也正好解释了为什么HashMap的数组长度要取2的整次幂

因为这样(数组长度-1)正好相当于一个“低位掩码”

“与”操作的结果就是散列值的高位全部归零,只保留低位值,用来做数组下标访问

以初始长度16为例,16-1=15

2进制表示是00000000 00000000 00001111

和某散列值做“与”操作如下,结果就是截取了最低的四位值

a781af04cfeb255752ceee6f09992612.jpeg

但这时候问题就来了,这样就算我的散列值分布再松散,要是只取最后几位的话,碰撞也会很严重

这时候“扰动函数”的价值就体现出来了

717038a03560ddbd85b9ab17073b749f.jpeg

右位移16位,正好是32位一半,自己的高半区和低半区做异或,就是为了混合原始hashCode的高位和低位,以此来加大低位的随机性
而且混合后的低位掺杂了高位的部分特征,这样高位的信息也被变相保留下来。

index的运算规则是

e.hash & (newCap - 1)

newCap是2的幂,所以newCap - 1的高位全0

若e.hash值只用自身的hashcode,index只会和e.hash的低位做&操作.这样一来,index的值就只有低位参与运算,高位毫无存在感,从而会带来哈希冲突的风险

所以在计算key的hashCode时,用其自身hashCode与其低16位做异或操作

这也就让高位参与到index的计算中来了,即降低了哈希冲突的风险又不会带来太大的性能问题

4.3 Put方法

0ca28fb5a8d386be6fa1f392f89c6c44.jpeg 17bc9e0350a702b519541611923ef3e6.jpeg 8c17f81e06c1f84be8cb1a323dba1384.jpeg

①.判断键值对数组table[i]是否为空或为null,否则执行resize()进行扩容

②.根据键值key计算hash值得到插入的数组索引i,如果table[i]==null,直接新建节点添加,转向⑥,如果table[i]不为空,转向③

③.判断table[i]的首个元素是否和key一样,如果相同直接覆盖value,否则转向④,这里的相同指的是hashCode以及equals

④.判断table[i] 是否为treeNode,即table[i] 是否是红黑树,如果是红黑树,则直接在树中插入键值对,否则转向⑤

⑤.遍历table[i],判断链表长度是否大于8,大于8的话把链表转换为红黑树,在红黑树中执行插入操作,否则进行链表的插入操作;遍历过程中若发现key已经存在直接覆盖value即可

⑥.插入成功后,判断实际存在的键值对数量size是否超多了最大容量threshold,如果超过,执行resize()扩容在构造函数中最多也只是设置了initialCapacity、loadFactor的值,并没有初始化table,table的初始化工作是在put方法中进行的.

4.4 resize

7209d17a95fb297565ab27ac5ec6ae6b.jpeg

扩容(resize)就是重新计算容量,向HashMap对象里不停的添加元素,内部的数组无法装载更多的元素时,就需要扩大数组的长度.
当然Java里的数组是无法自动扩容的,方法是使用一个新的数组代替已有的容量小的数组

4591f04ab6096fafaffb48ba484fb591.jpeg 4.5 getOrDefault

getOrDefault() 方法获取指定 key 对应对 value,如果找不到 key ,则返回设置的默认值。

23723ce3900bd2f6eda68f37169acea3.jpeg

5 单线程rehash

单线程情况下,rehash无问题

1c0f80cc510a35fa1587b39ffbd56220.jpeg

6 多线程并发下的rehash

这里假设有两个线程同时执行了put操作并引发了rehash,执行了transfer方法,并假设线程一进入transfer方法并执行完next = e.next后,因为线程调度所分配时间片用完而“暂停”,此时线程二完成了transfer方法的执行。

7 Fast-fail

产生原因

在使用迭代器的过程中如果HashMap被修改,那么ConcurrentModificationException将被抛出,也即Fast-fail策略。

当HashMap的iterator()方法被调用时,会构造并返回一个新的EntryIterator对象,并将EntryIterator的expectedModCount设置为HashMap的modCount(该变量记录了HashMap被修改的次数)。

在通过该Iterator的next方法访问下一个Entry时,它会先检查自己的expectedModCount与HashMap的modCount是否相等,如果不相等,说明HashMap被修改,直接抛出ConcurrentModificationException。该Iterator的remove方法也会做类似的检查。该异常的抛出意在提醒用户及早意识到线程安全问题。

线程安全解决方案

单线程条件下,为避免出现ConcurrentModificationException,需要保证只通过HashMap本身或者只通过Iterator去修改数据,不能在Iterator使用结束之前使用HashMap本身的方法修改数据。因为通过Iterator删除数据时,HashMap的modCount和Iterator的expectedModCount都会自增,不影响二者的相等性。如果是增加数据,只能通过HashMap本身的方法完成,此时如果要继续遍历数据,需要重新调用iterator()方法从而重新构造出一个新的Iterator,使得新Iterator的expectedModCount与更新后的HashMap的modCount相等。

多线程条件下,可使用Collections.synchronizedMap方法构造出一个同步Map,或者直接使用线程安全的ConcurrentHashMap.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值