前言
HashMap在java程序中使用颇为频繁,因此掌握HashMap的底层实现显得格外重要。相信大家也知道HashMap是非线程安全的,在多线程环境下应该避免使用HashMap,而应该使用线程安全的ConcurrentHashMap。那么HashMap在多线程环境下到底有什么问题,为什么存在这样的问题,以及jdk1.6及1.8以上实现的差异在哪?本文围绕这几个问题展开,逐一解答所有疑问。
HashMap底层数据结构及问题分析
jdk1.6
jdk1.6的HashMap底层数据结构相当简单,也是大家比较熟悉的数据结构---数组+单向链表。jdk1.6通过数组和链表的组合以拉链法的方式实现HashMap。结构如下图所示:
拉链法哈希表
key位置确定方式为pos=hashcode(key) % len,所有冲突的key通过单链表串起来。当HashMap的元素个数超过某个负载值(由负载因素决定)时,会进行扩容,并将所有元素rehash后放置在扩容后的哈希表中,jdk1.6的扩容逻辑如下:
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {
Entry<K,V> next = e.next;
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
这段代码逻辑不难,这里简单解读下上述代码做的事情:遍历旧哈希表中所有单链表,找到元素e在新哈希表的位置,然后将其插入到该位置对应链表的头部。循环完后,所有的元素都搬到新哈希表中。由此可以看出,这里采用的是头插入法,这样每次插入时不用遍历链表,提高了性能。但是这里存在一个潜在的风险:在多线程环境下,容易出现循环引用导致死循环。下面具体分析下这种场景。
假设有两个线程A、B同时对同一个HashMap进行插值操作,并且HashMap容量已到达阈值需要扩容。这时,便会出现并发扩容的情况。假设线程A先执行到Entry<K,V> next = e.next;此时A线程对应哈希表的状态如下:
哈希表状态-A
接着,操作系统将A线程挂起,B线程被调度执行,并执行完do while循环中的所有指令,此时B线程对应哈希表状态为:
我们可以看到,B执行完一把while循环后,12和20的指向恰好反过来了,这正是头插入法的效果。现在20的下一个元素是12。这时,如果线程A再次被调度执行,那么意外就出现了,因为此时在A线程看来e指向的是12,此时执行e.next = newTable[i];那么其实就是将12的下一个元素再次指向了20,此时的转态如下:
死循环状态
从上图可以看出,12的next引用20,20的next引用12,导致死循环。
jdk1.8
上一小节我们分析了jdk1.6的HashMap在并发扩容时会导致死循环,本小节我们来看看jdk1.8中HashMap的扩容时如何实现的。和jdk1.6中的HashMap类似,底层数据结构也是采用拉链法实现的hash表,不同的是当链表的元素个数达到8时,链表会转换为红黑树以提高查询的性能。本文的重点是分析扩容问题,因此对于红黑树暂且不讨论(网上一搜一大把)。jdk1.8扩容的逻辑如下:
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
else { // zero initial threshold signifies using defaults
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
table = newTab;
if (oldTab != null) {
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}
代码有点长,我们只关心主要扩容执行部分--for循环里。jdk1.8这块的实现逻辑比1.6绕,很多同学一开始很难理清楚,这里简单解释下:和1.6一样也是遍历原始hash表中所有链表,不同的是,在1.8中不是每遍历一个元素就往新hash表中插,而是提前将一个链表中的元素分别组织成低槽位和高槽位的链表,然后再分别将两个链表插入到新hash表中对应的位置。这里比较难理解的是一个单链表为何能拆成两个不同的链表,且保证链表中的元素确实在同一槽位?这里做个论证,假设有个长度为len的hash表,那么第i槽位对应的key的hash值只可能为i、len+i、2*len+i、... 、n*len+i。由于HashMap扩容是翻倍的,即扩容到原来的2倍,因此扩容后的长度为2*len,那之前旧表中第i槽位的元素rehash后在新表中的槽位为:i%2len、(len+i)%2len、(2*len+i)%2len、... 、(n*len+i)%2n,很明显(k*len+i)%2len(k为偶数)的值为i,(k*len+i)%2len(k为奇数)的值为i+len,所以rehash后旧表中第i槽位的key会落在新表第i或者第i+len槽位,这就解释了为什么旧表中一个链表会拆分为两个链表。还是以上面的HashMap为例1.8扩容后的结果如下:
可以看出,扩容后12和20依然在同一槽位,而且顺序也没变,由于不像1.6使用头插入法, 因此在多线程场景下不会出现死循环。那是不是1.8的HashMap就线程安全了呢?答案是否定的,do while循环进行链表拼接时,由于不是原子操作,会导致拼接覆盖的情况,导致数据丢失。
小结
本文主要介绍了HashMap在多线程环境下导致的问题及其原因,欢迎大家沟通交流。
网友评论