HashMap线程不安全问题解析

 更新时间:2023年11月02日 08:44:59   作者:Heloise_yangyuchang  
这篇文章主要介绍了HashMap线程不安全问题解析,HashMap的线程不安全体现在会造成死循环、数据丢失、数据覆盖等问题,其中死循环和数据丢失是在JDK1.7中出现的问题,在JDK1.8中已经得到解决,但是1.8中仍会有数据覆盖这样的问题,需要的朋友可以参考下

一、概述

结论:HashMap的线程不安全体现在会造成死循环、数据丢失、数据覆盖等问题。其中死循环和数据丢失是在JDK1.7中出现的问题,在JDK1.8中已经得到解决,但是1.8中仍会有数据覆盖这样的问题。HashMap是线程不安全的,线程安全场景应该使用ConcurrentHashMap。

HashMap的线程不安全主要是发生在扩容方法中,JDK1.7中HashMap的transfer函数如下:

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;
            }
        }
    } 

HashMap的扩容操作(先扩容在头插法插入)会重新定位每个桶的下标,并采用头插法将元素迁移到新数组中。头插法会将链表的顺序翻转,这也是造成死循环和数据丢失的关键。

二、JDK1.7中HashMap扩容分析

比如现在有两个线程A、B同时对下面这个HashMap进行扩容操作:

在这里插入图片描述

正常扩容后的结果如下(7%4=3%4=3):

在这里插入图片描述

但是当线程A执行到上面transfer函数的第11行代码时,CPU时间片耗尽,线程A被挂起,即

 newTable[i] = e; //此处挂起,此时还没有执行

此时线程A中:e=3、next=7、e.next=null

在这里插入图片描述

此时线程B开始执行,并且线程B成功的完成了数据迁移,如下:

在这里插入图片描述

这个是问题出现关键时间段,根据Java JMM,线程B执行完数据迁移后,此时主内存中newTable和table都是最新的,也就是说:7.next=3;3.next=null

此时线程A获得CPU时间片继续执行newTable[i] = e,将3放入新数组对应的位置,执行完此轮循环后线程A的情况如下

在这里插入图片描述

接着继续执行下一轮循环,此时e=7,从主内存中读取e.next时发现主内存中7.next=3,即next=3,并将7采用头插法的方式放入新数组中,并继续执行完此轮循环,结果如下:

在这里插入图片描述

继续执行下一次循环可以发现, e.next=null,所以此轮循环将会是最后一轮循环。接下来当执行完e.next=newTable[i]即3.next=7后,3和7之间就相互连接了,当执行完newTable[i]=e后,3被头插法重新插入到链表中,执行结果如下图所示:

在这里插入图片描述

到此线程A、B的扩容操作完成。

显然当线程A执行完后,HashMap中出现了环形结构,当在以后对该HashMap进行操作时会出现死循环。并且从上图可以发现,元素5在扩容期间被莫名的丢失了,这就发生了数据丢失的问题。

三、JDK1.8中的线程不安全

JDK1.7出现的问题,在JDK1.8中已经得到了很好的解决,JDK1.8直接在resize函数中完成了数据迁移。在进行元素插入时使用的是尾插法然后在扩容。

但是在1.8中仍会有数据覆盖这样的问题,先看put源码:

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
        if ((p = tab[i = (n - 1) & hash]) == null) //判断是否出现hash碰撞,如果没有hash碰撞则直接插入元素,此处线程不安全
            tab[i] = newNode(hash, key, value, null);
        else {
            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) { // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold) //++size此处线程不安全
            resize();
        afterNodeInsertion(evict);
        return null;
    }

其中代码if ((p = tab[i = (n - 1) & hash]) == null) 是判断是否出现hash碰撞: 比如两个线程A、B都在进行put操作,并且hash函数计算出的插入下标是相同的,当线程A执行完第六行代码后由于时间片耗尽导致被挂起,而线程B得到时间片后在该下标处插入了元素,完成了正常的插入,然后线程A获得时间片,由于之前已经进行了hash碰撞的判断,所有此时不会再进行判断,而是直接进行插入,这就导致了线程B插入的数据被线程A覆盖了,从而线程不安全。

还有一种情况就是代码 if (++size > threshold)中的++size: 同样还是线程A、B,这两个线程同时进行put操作时,假设当前HashMap的zise大小为10,当线程A执行到此行代码时,从主内存中获得size的值为10后准备进行+1操作,但是由于时间片耗尽只好让出CPU,线程B快乐的拿到CPU还是从主内存中拿到size的值10进行+1操作,完成了put操作并将size=11写回主内存,然后线程A再次拿到CPU并继续执行(此时size的值仍为10),当执行完put操作后,还是将size=11写回内存,此时线程A、B都执行了一次put操作,但是size的值只增加了1,所有说还是由于数据覆盖又导致了线程不安全。

四、总结

HashMap的线程不安全主要体现在两个方面:

1.在JDK1.7中,当并发执行扩容操作时会造成环形链和数据丢失的情况。

2.在JDK1.8中,在并发执行put操作时会发生数据覆盖的情况。

到此这篇关于HashMap线程不安全问题解析的文章就介绍到这了,更多相关HashMap线程不安全内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • SpringMVC中MultipartFile上传获取图片的宽度和高度详解

    SpringMVC中MultipartFile上传获取图片的宽度和高度详解

    本篇文章主要介绍了SpringMVC中MultipartFile上传获取图片的宽度和高度,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2017-05-05
  • springboot整合solr的方法详解

    springboot整合solr的方法详解

    这篇文章主要介绍了springboot整合solr的方法详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2019-08-08
  • Java中内核线程理论及实例详解

    Java中内核线程理论及实例详解

    在本篇文章里小编给大家整理了一篇关于Java中内核线程理论及实例详解内容,有兴趣的朋友们可以学习下。
    2021-03-03
  • Java通过反射查看类的信息示例

    Java通过反射查看类的信息示例

    这篇文章主要介绍了Java通过反射查看类的信息,结合实例形式详细分析了java基于反射获取类信息的相关原理与实现技巧,需要的朋友可以参考下
    2019-07-07
  • Spring依赖注入底层原理详解

    Spring依赖注入底层原理详解

    这篇文章主要介绍了Spring依赖注入底层原理详解,  依赖注入是一种设计模式,它将对象之间的依赖关系从代码中移除,并由容器来管理这些依赖关系,依赖注入的主要目的是降低代码的耦合度,使代码更加灵活和可维护,需要的朋友可以参考下
    2023-09-09
  • 全局请求添加TraceId轻松看日志

    全局请求添加TraceId轻松看日志

    这篇文章主要为大家介绍了全局请求添加TraceId,更加方便轻松的看日志,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-09-09
  • Spring Cache使用RedisCache案例解析

    Spring Cache使用RedisCache案例解析

    这篇文章主要介绍了Spring Cache使用RedisCache案例解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2019-10-10
  • 解决@Value注解不能注入static修饰的属性问题

    解决@Value注解不能注入static修饰的属性问题

    这篇文章主要介绍了解决@Value注解不能注入static修饰的属性问题,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2022-07-07
  • java实现简单验证码生成

    java实现简单验证码生成

    这篇文章主要介绍了java实现简单验证码生成,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2019-10-10
  • java双色球机选法程序解析

    java双色球机选法程序解析

    这篇文章主要为大家详细解析了java双色球机选法程序,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2020-01-01

最新评论