【java并发】造成HashMap非线程安全的原因

原创 2016年05月31日 11:18:19

0. 写在前面

  在前面我的一篇总结线程范围内共享数据文章中提到,为了数据能在线程范围内使用,我用了HashMap来存储不同线程中的数据,key为当前线程,value为当前线程中的数据。我取的时候根据当前线程名从HashMap中取即可。
  因为当初学习HashMap和HashTable源码的时候,知道HashTable是线程安全的,因为里面的方法使用了synchronized进行同步,但是HashMap没有,所以HashMap是非线程安全的。在上面提到的例子中,我想反正不用修改HashMap,只需要从中取值即可,所以不会有线程安全问题,但是我忽略了一个步骤:我得先把不同线程的数据存到HashMap中吧,这个存就可能出现问题,虽然我存的时候key使用了不同的线程名字,理论上来说是不会冲突的,但是这种设计或者思想本来就不够严谨。这也是由于一个网友看到我的那篇文章后给我提出的问题,我后来仔细推敲了下,重新温习了下HashMap的源码,再加上网上查的一些资料,在这里总结一下HashMap到底什么时候可能出现线程安全问题。
  我们知道HashMap底层是一个Entry数组,当发生hash冲突的时候,HashMap是采用链表的方式来解决的,在对应的数组位置存放链表的头结点。对链表而言,新加入的节点会从头结点加入。javadoc中有一段关于HashMap的描述:

此实现不是同步的。如果多个线程同时访问一个哈希映射,而其中至少一个线程从结构上修改了该映射,则它必须保持外部同步。(结构上的修改是指添加或删除一个或多个映射关系的任何操作;仅改变与实例已经包含的键关联的值不是结构上的修改。)这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象,则应该使用 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的写入操作丢失。

2. HashMap扩容的时候

  还是上面那个addEntry方法中,有个扩容的操作,这个操作会新生成一个新的容量的数组,然后对原数组的所有键值对重新进行计算和写入新的数组,之后指向新生成的数组。来看一下扩容的源码:

//用新的容量来给table扩容  
void resize(int newCapacity) {  
    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作为原始数组,这样也会有问题。所以在扩容操作的时候也有可能会引起一些并发的问题。

3. 删除HashMap中数据的时候

  删除键值对的源代码如下:

//根据指定的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进行包装一下。另外还得感谢那位网友,我对HashMap线程安全问题的认识又进了一步~


—–乐于分享,共同进步!
—–更多文章请看:http://blog.csdn.net/eson_15

版权声明:尊重博主原创文章,转载请注明出处

相关文章推荐

《Java困惑》:多并发情况下HashMap是否还会产生死循环

《Java困惑》:多并发情况下HashMap是否还会产生死循环今天本来想看下了ConcurrentHashMap的源码,ConcurrentHashMap是Java 5中支持高并发、高吞吐量的线程安全...

并发的HashMap为什么会引起死循环?

今天研读Java并发容器和框架时,看到为什么要使用ConcurrentHashMap时,其中有一个原因是:线程不安全的HashMap, HashMap在并发执行put操作时会引起死循环,是因为多线程会...

并发安全问题之HashMap

并发安全问题之HashMap 原文地址: http://my.oschina.net/xianggao/blog/393990#OSC_h2_1   目录[-] 并发问题的症状多...
  • zljjava
  • zljjava
  • 2016年09月26日 11:37
  • 321

HashMap的底层工作原理和并发问题

源码分析首先来看下HashMap一个典型的构造函数:transient HashMapEntry[] table;public HashMap(int capacity) { if (capac...

浅析HashMap与ConcurrentHashMap的线程安全性

本文要解决的问题: 最近无意中发现有很多对Map尤其是HashMap的线程安全性的话题讨论,在我的理解中,对HashMap的理解中也就知道它是线程不安全的,以及HashMap的底层算法采用了链地址法来...

HashMap在高并发下导致CPU过高

先用top命令定位哪些线程占用多: top - 18:14:46 up 200 days, 23:26, 2 users, load average: 95.13, 88.59, 79.51Tasks...

HashMap多线程并发问题分析

HashMap多线程并发问题分析

HashMap多线程死循环问题

正如上篇文中所说,HashMap不是线程安全的,在被多线程共享操作时,会有问题,具体什么问题呢,一直没有个清晰的理解,今天写了个测试程序调了一下,才明白其中道理。 主要是多线程同时put时,如果同时触...

HashMap为什么是线程不安全的?

一直以来只是知道HashMap是线程不安全的,但是到底HashMap为什么线程不安全,多线程并发的时候在什么情况下可能出现问题? HashMap底层是一个Entry数组,当发生hash冲突的时候,h...

HashMap为什么线程不安全

一直以来都知道HashMap是线程不安全的,但是到底为什么线程不安全,在多线程操作情况下什么时候线程不安全? 让我们先来了解一下HashMap的底层存储结构,HashMap底层是一个Entry数组,...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:【java并发】造成HashMap非线程安全的原因
举报原因:
原因补充:

(最多只允许输入30个字)