并发下诡异的HashMap

最近研读《Java高并发程序设计》葛一鸣、郭超编著，读到2.8.3时，题目便是并发下诡异的HashMap，摘抄如下：

-----------摘抄开始--------------

HashMap同样不是线程安全的。当你使用多线程访问HashMap时，也可能会遇到意想不到的错误。不过和ArrayList不同，HashMap的问题似乎更加诡异。

package cn.baokx;

import java.util.HashMap;
import java.util.Map;

public class HashMapMultiThread {
static Map<String,String> map = new HashMap<String,String>();
public static class AddThread implements Runnable{
int start = 0 ;
public AddThread(int start){
this.start = start;
}
@Override
public void run() {
for (int i = 0; i < 100000; i+=2) {
map.put(Integer.toString(i), Integer.toBinaryString(i));

}
}
}

public static void main(String[] args) throws InterruptedException {

Thread t1 = new Thread(new HashMapMultiThread.AddThread(0));
Thread t2 = new Thread(new HashMapMultiThread.AddThread(1));
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(map.size());
}
}

上述代码使用t1和t2两个线程同时对HashMap进行put()操作，如果一切正常，我们期望得到的map.size()就是100000.但实际上，你可能会得到以下三种情况(注意，这里使用JDK7进行试验)：

第一：程序正常结束，并且结果也是符合预期的。HashMap的大小为100000.

第二：程序正常结束，但结果不符合预期，而是一个小于100000的数字，比如98868.

第三：程序永远无法结束。

对于前两种可能，和ArrayList的情况非常类似，因此，不必过多解释。而对于第三种情况，如果是第一次看到，我想大家一定会觉得特别惊讶，因为看似非常正常的程序，怎么可能就结束不了呢?

注意：请读者谨慎尝试以上代码，由于这段代码很可能占用两个CPU核，并使它们的CPU占有率达到100%。如果CPU性能较弱，可能导致死机。请先保存资料再进行尝试。

打开任务管理器，你会发现，这段代码占用了极高的CPU，最有可能的表示是占用了两个CPU核，并使得这两个核的CPU使用率达到100%。这非常类似死循环的情况。

使用jstack工具显示程序的线程信息，如下所示。其中jps可以显示当前系统中所有的java进程。二jstack可以打印给定的java进程的内部线程及其堆栈。



我们会很容易找到我们的t1、t2和main线程：



可以看到，主线程main处于等待状态，并且这个等待是由于join方法引起的，符合我们的预期，二t1和t2两个线程都处于Runnable状态，并且当前执行语句为HashMap.put()方法。查看put()方法的第498行代码，如下所示：

for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}

可以看到，当前这两个线程正在遍历HashMap的内部数据。当前所处循环乍看之下是一个迭代遍历，就如同遍历一个链表一样。但在此时此刻，由于多线程的冲突，这个链表的结构已经遭到破坏，链表成环了!当链表成环时，上述的迭代就等同于一个死循环，如图2.9所示，展示了最简单的一种环状结构，Key1和Key2互为对方的next元素。此时，通过next引用遍历，将形成死循环。



这个死循环的问题，如果一旦发生，着实可以让你郁闷一把。本章的参考资料中也给出了一个真实的按理。但这个死循环的问题在JDK8中已经不存在了。由于JDK8对HashMap的内部做了大规模的调整，一次规避了这个问题。但即使这样，贸然在多线程环境下使用HashMap一人会导致内部数据不一致。最简单的解决方案就是使用ConcurrentHashMap代替HashMap。

-----------摘抄结束--------------

以上内容为书上内容的摘抄，看完以后对红色标注的部分"但在此时此刻，由于多线程的冲突，这个链表的结构已经遭到破坏，链表成环了!"无法理解，到底是什么情况下导致链表成环了呢？书中并没有展开，通过自己最近几天的查询和学习，确认了链表成环的原因，在此分享出来。

HashMap内部通过一个Entry<K,V>[]
table来存储数据，当调用put方法时，根据key的hashcode进行Hash计算，得出一个数组下标，然后将Entry对象放至相应位置，在这种情况下可能发生不同的hashcode进行Hash计算得到的下标相同的情况，这种情况下，会将Entry进行链式存储(Entry内部本身定义了Entry类型的next属性，据此实现链式存储)，和ArrayList一样，table的长度会有一个初始值(HashMap默认为16)和load_factor(默认0.75f)，当数组的“使用率(即不为空的元素数量/长度)”达到load_factor时，就需要对数组进行扩容，扩容的时候需要定义一个新的数组，并把旧的数组中的Entry分配到新的数组中。

对于HashMap内部的存储方式，可参考博客，/article/10711138.html，里面讲的比较详细。

源代码分析如下所示：

//注意put方法是有返回值的
public V put(K key, V value) {
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
//HashMap允许有一个key为null的键值对
if (key == null)
return putForNullKey(value);
int hash = hash(key);
//计算下标
int i = indexFor(hash, table.length);
//循环下标处的Entry链表
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
//hash值相等且key==或equals匹配，则替换value值并把旧值返回
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}

modCount++;
//若循环Entry链表未匹配到，则加一个Entry
addEntry(hash, key, value, i);
return null;
}

//新增一个Entry
void addEntry(int hash, K key, V value, int bucketIndex) {
//若满足条件则需要扩容
if ((size >= threshold) && (null != table[bucketIndex])) {
resize(2 * table.length);
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}

createEntry(hash, key, value, bucketIndex);
}

//扩容
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}

//创建一个容量更大的新的数组
Entry[] newTable = new Entry[newCapacity];
//将旧数组中的Entry数据转移至新的数组
transfer(newTable, initHashSeedAsNeeded(newCapacity));
table = newTable;
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}

//转移数据
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
//注意
e.next = newTable[i];
//注意
newTable[i] = e;
e = next;
}
}
}

注意：上面的transfer方法，在多线程的情况下，会出现newTable[i].next=newTable[i]的情况，这也是文中提到的链表成环的原因。
为了验证我们的判断，在创建数组的时候未数组提供初始化容量和影响因子，目的是不让扩容的情况发生，代码如下：

public class HashMapMultiThread {
static Map<String,String> map = new HashMap<String,String>(120000,1.0f);
public static class AddThread implements Runnable{
int start = 0 ;
public AddThread(int start){
this.start = start;
}
@Override
public void run() {
for (int i = 0; i < 100000; i+=2) {
map.put(Integer.toString(i), Integer.toBinaryString(i));

}
}
}

public static void main(String[] args) throws InterruptedException {

Thread t1 = new Thread(new HashMapMultiThread.AddThread(0));
Thread t2 = new Thread(new HashMapMultiThread.AddThread(1));
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(map.size());
}
}

通过验证，不再出现死循环的问题(若觉得这样修改仍不能确定是由于代码修改导致不再死循环，可以增加线程数，再对比修改前后的运行结果)。

以上就是对此疑问的分析。