¶引导
在了解HashMap
之前,我们应该先明白两个概念:Hash
和Map
,这可以帮助我们更容易了解HashMap
的运行原理。
那么何为Hash
,又何为Map
呢?
¶Hash
之前写过一篇关于Hash的文章 Hash
¶Map
Map是一种K-V
形式的数据结构,一个唯一的key,会唯一对应一个value。也就是说,在Map容器里不允许两个一模一样的key。
一个简单的Map结构如下:
1 | { |
对于这种数据结构,并且Map会对外提供一些方法来实现对内部数据的操作:
1 | V put(K key, V value) |
可见Map对于我们操作K-V
形式的数据非常方便,实现的方式有很多,最简单粗暴的实现方式是使用List
来存储每一个K-V
组对,对于每种方法的实现只需要暴力循环碰撞即可,对于少量数据这种做法未必不可,如果数据量庞大之千万,我们就要换一种更加高效,速度更快的实现方式:HashMap
。
¶HashMap
Map在Java中的实现有很多,HashMap
便是其中之一,在JDK
漫长的版本更新中,HashMap
的实现也是在不断的更新着:
- <=JDK1.7:Table数组 + Entry链表
- >=JDK1.8:Table数组 + Entry链表/红黑树
本文我们跳过JDK1.7的实现,来看一下1.8中HashMap
源码所带来的魅力冲击!
¶实现原理
对于各个版本的HashMap
实现原理,主线流程都是一成不变的:
这里有两个数据结构需要我们知道:
- Table:哈希表,存放Node元素。
- Node:结点元素,存放
K-V
组对信息,其结构是一个链表/红黑树。
另外,在HashMap内部有一些关键属性我们也要了解一下:
- DEFAULT_INITIAL_CAPACITY:Table数组初始长度,默认为
1 << 4
,2^4
= 16。 - MAXIMUM_CAPACITY:Table数组最高长度,默认为
1 << 30
,2^30
= 1073741824。 - DEFAULT_LOAD_FACTOR:负载因子,当总元素数 > 数组长度 * 负载因子时,Table数组将会扩容,默认为0.75。
- TREEIFY_THRESHOLD:树化阈值,当单个Table内Node数量超过该值,则会将链表转化为红黑树,默认为8。
- UNTREEIFY_THRESHOLD:链化阈值,当扩容期间单个Table内Entry数量小于该值,则将红黑树转化为链表,默认为6。
- MIN_TREEIFY_CAPACITY:最小树化阈值,当Table所有元素超过改值,才会进行树化(为了防止前期阶段频繁扩容和树化过程冲突)。
- size:Table数组当前所有元素数。
- threshold:下次扩容的阈值(数组长度 * 负载因子)
HashMap的内部有着一个Table数组,而这个数组的初始长度为DEFAULT_INITIAL_CAPACITY
参数值,Table数组存放的元素类型就是Node,它是一个单向链表:
1 | static class Node<K,V> implements Map.Entry<K,V> { |
每个Table中存的Node元素相当于链表的header
,next
指向下一个结点,而这种链式结构的存在正是为了解决hash冲突
:
hash冲突:两个元素的经过Hash散列之后分在同一个组内,我们将之解释为Hash冲突
在JDK1.7之前的版本,hash冲突的解决方法是将被冲突的Node结点放于一个链表中,而Table中的元素则是链头,当然在JDK1.8中,当Table中链长超过TREEIFY_THRESHOLD
阈值后,将会将链表转变为红黑树的实现TreeNode
:
1 | static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> { |
当发生hash冲突的Node不断变多,那么这个链将会越来越长,那么遍历碰撞key时的耗时就会不断增加,这也就直接导致了性能的不足,从JDK1.8开始,HashMap对于单个Table中的Node超出某个阈值时,将会开始树化操作(链表转化为红黑树),这对于搜索的性能将会有很大的提升,而插入和删除的操作所带来的性能影响微乎其微。
¶put方法
在HashMap
的内部会有一个Table数组,这个数组的当前长度就是我们要实现映射的目标范围,当我们执行put
方法时,key
和value
要经历这些事情:
- 通过
Hash
散列获取到对应的Table - 遍历Table下的Node结点,做更新/添加操作
- 扩容检测
具体实现我们可以根据源码来详细了解一下:
1 | final V putVal(int hash, K key, V value, boolean onlyIfAbsent, |
对于其过程中的关于Node链表和红黑树的转换过程我们可以暂时屏蔽掉,那么整个流程并不是很绕,那么我们继续深入的来看一下HashMap的扩容实现。
¶resize方法
HashMap的扩容大致的实现是将老Table数组中所有的Entry取出来,重新对其hashcode做Hash
散列到新的新的Table之中,也就是一个re-put
的过程,具体还是通过源码来讲解:
1 | final Node<K,V>[] resize() { |
¶get方法
在我们看完HashMap对于put方法的实现之后,get方法则显得简单易懂,其代码与put相近无几,主要差别是没有了扩容和添加/更新的操作:
1 | final Node<K,V> getNode(int hash, Object key) { |
¶containsKey方法
根据get方法的结果是否为空就可以直到是否包含该key:
1 | public boolean containsKey(Object key) { |
¶remove方法
同样类似于put操作,首先会查找对应的key所在位置,如果为空,则不操作,反之,将之移除:
1 | final Node<K,V> removeNode(int hash, Object key, Object value, |
¶为何线程不安全?
看完了HashMap的实现之后,就该谈一谈它为什么存在线程安全问题!
¶数据丢失
首先,我们将目光放在put方法的实现中,假设有两个线程在同时进行put操作,对应的数据分别为:
1 | thread-1: put(1, 'abc'); |
假设此时Hash表的长度为10,且已经有两个元素在,负载因子为默认值0.75f,那么操作过程一定不会扩容,并且两个线程put的key都是1,那么它们将会分配到同一个table中,下方代码为put方法中的其中一段,其主要作用是遍历当前表内Node,寻找与当前key一样的Node结点,之后再做添加/更新操作。
1 | for (int binCount = 0; ; ++binCount) { |
假设两个线程同时执行到了A
这个位置,此时获取到的p
是统一个对象,下一刻,cpu运转,两个线程同时运行,那么p.next
的值将会是最后一个线程put的value值,而前一个则会丢失,这就会导致丢数据的情况!
当然该情景同样会发生于resize
和remove
操作,至于为什么,大家可以思考一下!
¶size不准确
这个就很简单了,为什么不准确呢,来看一下size变量在HashMap内部的定义:
1 | transient int size; |
内存不可见并且增减操作未加锁,多线程操作下属于非原子操作!
¶闭环死锁
这个问题在JDK1.8版本的HashMap中已经不存在了,至于为啥,我要先讲一下在1.8之前的HashMap为什么会存在闭环死锁问题!
从闭环
这个名词上我们分析一下是什么问题,什么是闭环的,如果链表形成了一个环会不会就是闭环呢?而链表如何才会形成环?带着这些问题,我们在脑海中抽象出一个模型:
1 | graph LR |
假设某一个Table中的Node链表发生了上述问题,那么我们在遍历时进行do{ }while ((e = e.next) != null);
操作就会发生死锁的问题,那么看来我们的猜想方向是正确的,那么我们就具体分析一下HashMap在什么操作之中会产生闭环的问题,不过在此之前,我们要明白因果:
1 | 因:??? |
我们知道,只有当两个结点内部的next
相互引用对方的时候才会死锁,这种场景只能在两个已经存在同一个链上的结点同时以相反的方向
被操作next
引用的时候才会发生,而在HashMap内部,符合这种场景的只有一个方法:resize
,那我们就来看一下JDK1.7的resize
方法实现:
1 | void resize(int newCapacity) { |
进入transfer
方法中,其内部实现了扩容过程:
1 | void transfer(Entry[] newTable, boolean rehash) { |
我们发现,在JDK1.7的HashMap的扩容实现中,老的Table中的Node链的顺序赋值给新的Table中时的操作是反置的:
1 | e.next = newTable[i]; |
上述操作是将当前Node的next指针指向当前Table的头结点,之后当前Node又变为了Table的头结点,此时假设A、B两个线程同时执行到了transfer
方法中的A
位置,并且此时的oldTable
和newTable
的结构是这样的:
1 | oldTable[] |
如果很巧,两个线程在同一个CPU上执行,那么就会存在一个抢占时间片的场景,假设A先抢到了时间片,然后执行一番操作之后,oldTable
和newTable
的结构如下:
1 | oldTable[] |
之后还没等它做oldTable = newTable
操作,B抢到了时间片,并也做了同样一番操作,oldTable
和newTable
的结构如下:
1 | oldTable[] |
此时A或者B谁先oldTable = newTable
已经无所谓了,因为newTable
中已经产生了闭环,之后在进行get或者put操作时,如果不小心触发到了while循环,那将会一直死循环:
1 | do{ |
从上述场景产生的过程中我们发现,a -> c -> b -> a
这种闭环问题的罪魁祸首是因为1.7中的HashMap在扩容时为了免去再次遍历链表,很聪明的将当前结点作为新链表的头结点,这就会导致顺序反转,所以无序化导致了闭环的产生,而这种问题不仅仅是在HashMap中体现,Mysql的死锁问题的原因常常也是因为反序加行锁导致的!
而在开头说过,JDK1.8已经避免了这个问题,这是为什么呢?看下代码就知道了:
1 | else { // preserve order |
同样是扩容的操作,JDK1.8中的HashMap通过两个链分别去存储头结点和尾结点以保证它有序,并且不会频繁的去赋值newTable
,而是在循环之后直接赋值(请注意A、B标记处),这样就非常简单的避免了产生闭环的陷阱!