形成HashMap非线程安全的缘由

咱们知道 HashMap 底层是一个 Entry 数组,当发生 hash 冲突的时候,HashMap 是采用链表的方式来解决的,在对应的数组位置存放链表的头结点。对链表而言,新加入的节点会从头结点加入。javadoc 中有一段关于 HashMap 的描述:java

此实现不是同步的。若是多个线程同时访问一个哈希映射,而其中至少一个线程从结构上修改了该映射,则它必须保持外部同步。(结构上的修改是指添加或删除一个或多个映射关系的任何操做;仅改变与实例已经包含的键关联的值不是结构上的修改。)这通常经过对天然封装该映射的对象进行同步操做来完成。若是不存在这样的对象,则应该使用 Collections.synchronizedMap 方法来“包装”该映射。最好在建立时完成这一操做,以防止对映射进行意外的非同步访问,以下所示:
Map m = Collections.synchronizedMap(new HashMap(...));
能够看出,解决 HashMap 线程安全问题的方法很简单,下面我简单分析一下可能会出现线程问题的一些地方。数组

  1. 向HashMap中插入数据的时候

在 HashMap 作 put 操做的时候会调用到如下的方法:安全

//向HashMap中添加Entry
void addEntry(int hash, K key, V value, int bucketIndex) {并发

if ((size >= threshold) && (null != table[bucketIndex])) {
    resize(2 * table.length); //扩容2倍
    hash = (null != key) ? hash(key) : 0;
    bucketIndex = indexFor(hash, table.length);
}

createEntry(hash, key, value, bucketIndex);

}
//建立一个Entry
void createEntry(int hash, K key, V value, int bucketIndex) {高并发

Entry<K,V> e = table[bucketIndex];//先把table中该位置原来的Entry保存
//在table中该位置新建一个Entry,将原来的Entry挂到该Entry的next
table[bucketIndex] = new Entry<>(hash, key, value, e);
//因此table中的每一个位置永远只保存一个最新加进来的Entry,其余Entry是一个挂一个,这样挂上去的
size++;

}
如今假如 A 线程和 B 线程同时进入 addEntry,而后计算出了相同的哈希值对应了相同的数组位置,由于此时该位置还没数据,而后对同一个数组位置调用 createEntry,两个线程会同时获得如今的头结点,而后 A 写入新的头结点以后,B 也写入新的头结点,那 B 的写入操做就会覆盖A的写入操做形成 A 的写入操做丢失。this

  1. HashMap扩容的时候

仍是上面那个 addEntry 方法中,有个扩容的操做,这个操做会新生成一个新的容量的数组,而后对原数组的全部键值对从新进行计算和写入新的数组,以后指向新生成的数组。来看一下扩容的源码:线程

//用新的容量来给table扩容
void resize(int newCapacity) {code

Entry[] oldTable = table; //保存old table  
int oldCapacity = oldTable.length; //保存old capacity  
// 若是旧的容量已是系统默认最大容量了,那么将阈值设置成整形的最大值,退出    
if (oldCapacity == MAXIMUM_CAPACITY) {  
    threshold = Integer.MAX_VALUE;  
    return;  
}  

//根据新的容量新建一个table  
Entry[] newTable = new Entry[newCapacity];  
//将table转换成newTable  
transfer(newTable, initHashSeedAsNeeded(newCapacity));  
table = newTable;  
//设置阈值  
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);

}
那么问题来了,当多个线程同时进来,检测到总数量超过门限值的时候就会同时调用 resize操做,各自生成新的数组并 rehash 后赋给该 map 底层的数组 table,结果最终只有最后一个线程生成的新数组被赋给 table 变量,其余线程的均会丢失。并且当某些线程已经完成赋值而其余线程刚开始的时候,就会用已经被赋值的 table 做为原始数组,这样也会有问题。因此在扩容操做的时候也有可能会引发一些并发的问题。对象

  1. 删除HashMap中数据的时候

删除键值对的源代码以下:ci

//根据指定的key删除Entry,返回对应的value
public V remove(Object key) {

Entry<K,V> e = removeEntryForKey(key);  
return (e == null ? null : e.value);

}

//根据指定的key,删除Entry,并返回对应的value
final Entry<K,V> removeEntryForKey(Object key) {

if (size == 0) {  
    return null;  
}  
int hash = (key == null) ? 0 : hash(key);  
int i = indexFor(hash, table.length);  
Entry<K,V> prev = table[i];  
Entry<K,V> e = prev;  

while (e != null) {  
    Entry<K,V> next = e.next;  
    Object k;  
    if (e.hash == hash &&  
        ((k = e.key) == key || (key != null && key.equals(k)))) {  
        modCount++;  
        size--;  
        if (prev == e) //若是删除的是table中的第一项的引用  
            table[i] = next;//直接将第一项中的next的引用存入table[i]中  
        else  
            prev.next = next; //不然将table[i]中当前Entry的前一个Entry中的next置为当前Entry的next  
        e.recordRemoval(this);  
        return e;  
    }  
    prev = e;  
    e = next;  
}  

return e;

}
删除这一块可能会出现两种线程安全问题,第一种是一个线程判断获得了指定的数组位置i并进入了循环,此时,另外一个线程也在一样的位置已经删掉了i位置的那个数据了,而后第一个线程那边就没了。可是删除的话,没了倒问题不大。

再看另外一种状况,当多个线程同时操做同一个数组位置的时候,也都会先取得如今状态下该位置存储的头结点,而后各自去进行计算操做,以后再把结果写会到该数组位置去,其实写回的时候可能其余的线程已经就把这个位置给修改过了,就会覆盖其余线程的修改。

其余地方还有不少可能会出现线程安全问题,我就不一一列举了,总之 HashMap 是非线程安全的,在高并发的场合使用的话,要用 Collections.synchronizedMap 进行包装一下,或者直接使用 ConcurrentHashMap 都行。

关于 HashMap 的线程非安全性,就总结这么多,若有问题,欢迎交流,咱们一同进步~

相关文章
相关标签/搜索