jdk1.6及1.8 HashMap线程安全分析
前言
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
我们可以看到，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扩容后的结果如下：
扩容后的哈希表-1.8
可以看出，扩容后12和20依然在同一槽位，而且顺序也没变，由于不像1.6使用头插入法， 因此在多线程场景下不会出现死循环。那是不是1.8的HashMap就线程安全了呢？答案是否定的，do while循环进行链表拼接时，由于不是原子操作，会导致拼接覆盖的情况，导致数据丢失。
小结
本文主要介绍了HashMap在多线程环境下导致的问题及其原因，欢迎大家沟通交流。
