hashmap引起死循环

今天开发环境压测的时候出现cpu用满了情况，看线程堆栈，一堆线程都停留在org.apache.commons.collections4.map.AbstractHashedMap.put(AbstractHashedMap.java:285)，查看google源代码

public Object put(Object key, Object value) {
        key = convertKey(key);
        int hashCode = hash(key);
        int index = hashIndex(hashCode, data.length);
        HashEntry entry = data[index];
        while (entry != null) {
            if (entry.hashCode == hashCode && isEqualKey(key, entry.key)) {
                Object oldValue = entry.getValue();
                updateEntry(entry, value);
                return oldValue;
            }
            entry = entry.next;
        }

        addMapping(index, hashCode, key, value);
        return null;
    }

方法是非线程安全的，而addMapping方法会触发ensureCapacity扩容，而并发扩容就会容易导致死循环, 具体原因参考文章https://www.cnblogs.com/dongguacai/p/5599100.html

解决方法：

1、使用ConcurrentHashMap。

2、使用Collections.synchronizedMap(Mao<K,V> m)方法把HashMap变成一个线程安全的Map。

我copy了部分文章内容

正常的扩容过程

我们先来看下单线程情况下，正常的rehash过程

1、假设我们的hash算法是简单的key mod一下表的大小（即数组的长度）。

2、最上面是old hash表，其中HASH表的size=2，所以key=3,5,7在mod 2 以后都冲突在table[1]这个位置上了。

3、接下来HASH表扩容，resize=4，然后所有的<key,value>重新进行散列分布，过程如下：

在单线程情况下，一切看起来都很美妙，扩容过程也相当顺利。接下来看下并发情况下的扩容。

并发情况下的扩容

1、首先假设我们有两个线程，分别用红色和蓝色标注了。

2、扩容部分的源代码：

 1 void transfer(Entry[] newTable) {

 2         Entry[] src = table;

 3         int newCapacity = newTable.length;

 4         for (int j = 0; j < src.length; j++) {

 5             Entry<K,V> e = src[j];

 6             if (e != null) {

 7                 src[j] = null;

 8                 do {

 9                     Entry<K,V> next = e.next;

10                     int i = indexFor(e.hash, newCapacity);

11                     e.next = newTable[i];

12                     newTable[i] = e;

13                     e = next;

14                 } while (e != null);

15             }

16         }

17     }

3、如果在线程一执行到第9行代码就被CPU调度挂起，去执行线程2，且线程2把上面代码都执行完毕。我们来看看这个时候的状态：

4、接着CPU切换到线程一上来，执行8-14行代码，首先安置3这个Entry：

这里需要注意的是：线程二已经完成执行完成，现在table里面所有的Entry都是最新的，就是说7的next是3,3的next是null；现在第一次循环已经结束，3已经安置妥当。看看接下来会发生什么事情：

1、e=next=7;

2、e!=null,循环继续

3、next=e.next=3

4、e.next 7的next指向3

5、放置7这个Entry，现在如图所示：

放置7之后，接着运行代码：

1、e=next=3;

2、判断不为空，继续循环

3、next= e.next 这里也就是3的next 为null

4、e.next=7,就3的next指向7.

5、放置3这个Entry，此时的状态如图：

这个时候其实就出现了死循环了，3移动节点头的位置，指向7这个Entry;在这之前7的next同时也指向了3这个Entry。

代码接着往下执行，e=next=null，此时条件判断会终止循环。这次扩容结束了。但是后续如果有查询（无论是查询的迭代还是扩容），都会hang死在table【3】这个位置上。现在回过来看文章开头的那个Demo，就是挂死在扩容阶段的transfer这个方法上面。

出现上面这种情况绝不是我要在测试环境弄一批数据专门为了演示这种问题。我们仔细思考一下就会得出这样一个结论：如果扩容前相邻的两个Entry在扩容后还是分配到相同的table位置上，就会出现死循环的BUG。在复杂的生产环境中，这种情况尽管不常见，但是可能会碰到。