HashMap 线程不安全原因剖析(jdk1.7,jdk1.8)

我们都知道HashMap是线程不安全的,在多线程环境中不建议使用,但是其线程不安全主要体现在什么地方呢,本文将对该问题进行解密。

在jdk1.8中对HashMap做了很多优化,这里先分析在jdk1.7中的问题,相信大家都知道在jdk1.7多线程环境下HashMap容易出现死循环,这里我们先用代码来模拟出现死循环的情况:


 
 
  1. public  class HashMapTest {
  2.      public static void main(String[] args) {
  3.         HashMapThread thread0 =  new HashMapThread();
  4.         HashMapThread thread1 =  new HashMapThread();
  5.         HashMapThread thread2 =  new HashMapThread();
  6.         HashMapThread thread3 =  new HashMapThread();
  7.         HashMapThread thread4 =  new HashMapThread();
  8.         thread0.start();
  9.         thread1.start();
  10.         thread2.start();
  11.         thread3.start();
  12.         thread4.start();
  13.     }
  14. }
  15. class HashMapThread extends Thread {
  16.      private  static AtomicInteger ai =  new AtomicInteger();
  17.      private  static Map<Integer, Integer> map =  new HashMap<>();
  18.      @Override
  19.      public void run() {
  20.          while (ai.get() <  1000000) {
  21.             map.put(ai.get(), ai.get());
  22.             ai.incrementAndGet();
  23.         }
  24.     }
  25. }

 

上述代码比较简单,就是开多个线程不断进行put操作,并且HashMap与AtomicInteger都是全局共享的。

 

在多运行几次该代码后,出现如下死循环情形:

 

其中有几次还会出现数组越界的情况:

 

这里我们着重分析为什么会出现死循环的情况,通过jps和jstack命名查看死循环情况,结果如下:

 

从堆栈信息中可以看到出现死循环的位置,通过该信息可明确知道死循环发生在HashMap的扩容函数中,根源在transfer函数中,jdk1.7中HashMap的transfer函数如下:

 


 
 
  1. void transfer(Entry[] newTable, boolean rehash) {
  2.          int newCapacity = newTable.length;
  3.          for (Entry<K,V> e : table) {
  4.              while( null != e) {
  5.                 Entry<K,V> next = e. next;
  6.                  if (rehash) {
  7.                     e.hash =  null == e.key ?  0 : hash(e.key);
  8.                 }
  9.                  int i = indexFor(e.hash, newCapacity);
  10.                 e. next = newTable[i];
  11.                 newTable[i] = e;
  12.                 e = next;
  13.             }
  14.         }
  15. }

 

总结下该函数的主要作用:

在对table进行扩容到newTable后,需要将原来数据转移到newTable中,注意10-12行代码,这里可以看出在转移元素的过程中,使用的是头插法,也就是链表的顺序会翻转,这里也是形成死循环的关键点。

下面进行详细分析。

1.1 扩容造成死循环分析过程

 

前提条件,这里假设:

 

  1. hash算法为简单的用key mod链表的大小。

  2. 最开始hash表size=2,key=3,7,5,则都在table[1]中。

  3. 然后进行resize,使size变成4。

 

未resize前的数据结构如下:

 

 

如果在单线程环境下,最后的结果如下:

 

这里的转移过程,不再进行详述,只要理解transfer函数在做什么,其转移过程以及如何对链表进行反转应该不难。

 

然后在多线程环境下,假设有两个线程A和B都在进行put操作。线程A在执行到transfer函数中第11行代码处挂起,因为该函数在这里分析的地位非常重要,因此再次贴出来。

关注微信号:bjmsb10,备注:java,可以获取我整理的 N 篇最新Java 技术教程,都是干货。

 

此时线程A中运行结果如下:

 

线程A挂起后,此时线程B正常执行,并完成resize操作,结果如下:

 

 

这里需要特别注意的点:由于线程B已经执行完毕,根据Java内存模型,现在newTable和table中的Entry都是主存中最新值:7.next=3,3.next=null。

此时切换到线程A上,在线程A挂起时内存中值如下:e=3,next=7,newTable[3]=null,代码执行过程如下:

 


 
 
  1. newTable[3]=e ----> newTable[3]=3
  2. e=next ----> e=7

 

此时结果如下:

 

继续循环:

 


 
 
  1. e= 7
  2. next=e. next ---->  next= 3【从主存中取值】
  3. e. next=newTable[ 3] ----> e. next= 3【从主存中取值】
  4. newTable[ 3]=e ----> newTable[ 3]= 7
  5. e= next ----> e= 3

 

结果如下:

再次进行循环:


 
 
  1. e= 3
  2. next=e. next ---->  next= null
  3. e. next=newTable[ 3] ----> e. next= 7 即: 3. next= 7
  4. newTable[ 3]=e ----> newTable[ 3]= 3
  5. e= next ----> e= null

 

注意此次循环:e.next=7,而在上次循环中7.next=3,出现环形链表,并且此时e=null循环结束。

 

结果如下:

 

 

在后续操作中只要涉及轮询HashMap的数据结构,就会在这里发生死循环,造成悲剧。

 

1.2 扩容造成数据丢失分析过程

 

遵照上述分析过程,初始时:

 

 

线程A和线程B进行put操作,同样线程A挂起:

 

 

此时线程A的运行结果如下:

 

 

此时线程B已获得CPU时间片,并完成resize操作:

 

 

同样注意由于线程B执行完成,newTable和table都为最新值:5.next=null。

 

此时切换到线程A,在线程A挂起时:e=7,next=5,newTable[3]=null。

 

执行newtable[i]=e,就将7放在了table[3]的位置,此时next=5。接着进行下一次循环:

 


 
 
  1. e= 5
  2. next=e. next ---->  next= null,从主存中取值
  3. e. next=newTable[ 1] ----> e. next= 5,从主存中取值
  4. newTable[ 1]=e ----> newTable[ 1]= 5
  5. e= next ----> e= null

 

将5放置在table[1]位置,此时e=null循环结束,3元素丢失,并形成环形链表。并在后续操作HashMap时造成死循环。

 

 

在jdk1.8中对HashMap进行了优化,在发生hash碰撞,不再采用头插法方式,而是直接插入链表尾部,因此不会出现环形链表的情况,但是在多线程的情况下仍然不安全。

 

这里我们看jdk1.8中HashMap的put操作源码:

 


 
 
  1. final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
  2.                    boolean evict) {
  3.         Node<K,V>[] tab; Node<K,V> p;  int n, i;
  4.          if ((tab = table) ==  null || (n = tab.length) ==  0)
  5.             n = (tab = resize()).length;
  6.          if ((p = tab[i = (n -  1) & hash]) ==  null// 如果没有hash碰撞则直接插入元素
  7.             tab[i] = newNode(hash, key,  valuenull);
  8.          else {
  9.             Node<K,V> e; K k;
  10.              if (p.hash == hash &&
  11.                 ((k = p.key) == key || (key !=  null && key. equals(k))))
  12.                 e = p;
  13.              else  if (p instanceof TreeNode)
  14.                 e = ((TreeNode<K,V>)p).putTreeVal( this, tab, hash, key,  value);
  15.              else {
  16.                  for ( int binCount =  0; ; ++binCount) {
  17.                      if ((e = p.next) ==  null) {
  18.                         p.next = newNode(hash, key,  valuenull);
  19.                          if (binCount >= TREEIFY_THRESHOLD -  1// -1 for 1st
  20.                             treeifyBin(tab, hash);
  21.                          break;
  22.                     }
  23.                      if (e.hash == hash &&
  24.                         ((k = e.key) == key || (key !=  null && key. equals(k))))
  25.                          break;
  26.                     p = e;
  27.                 }
  28.             }
  29.              if (e !=  null) {  // existing mapping for key
  30.                 V oldValue = e. value;
  31.                  if (!onlyIfAbsent || oldValue ==  null)
  32.                     e. value =  value;
  33.                 afterNodeAccess(e);
  34.                  return oldValue;
  35.             }
  36.         }
  37.         ++modCount;
  38.          if (++size > threshold)
  39.             resize();
  40.         afterNodeInsertion(evict);
  41.          return  null;
  42. }

 

这是jdk1.8中HashMap中put操作的主函数, 注意第6行代码,如果没有hash碰撞则会直接插入元素。

 

如果线程A和线程B同时进行put操作,刚好这两条不同的数据hash值一样,并且该位置数据为null,所以这线程A、B都会进入第6行代码中。

 

假设一种情况,线程A进入后还未进行数据插入时挂起,而线程B正常执行,从而正常插入数据,然后线程A获取CPU时间片,此时线程A不用再进行hash判断了,问题出现:线程A会把线程B插入的数据给覆盖,发生线程不安全。

 

总结

 

首先HashMap是线程不安全的,其主要体现:

 

  1. 在jdk1.7中,在多线程环境下,扩容时会造成环形链或数据丢失。

  2. 在jdk1.8中,在多线程环境下,会发生数据覆盖的情况。

<think>嗯,用户想知道JavaHashMap在多线程环境下的问题及原因,特别是JDK1.7的死循环和JDK1.8的数据覆盖,还有解决方案。首先我得回忆一下HashMap同版本的结构差异。 JDK1.7用的是数组加链表,插入链表的时候是头插法,这样在扩容时可能会导致死循环。而JDK1.8改成了尾插法,并引入了红黑树,但数据覆盖的问题还存在。需要分版本解释问题。 然后,用户可能实际遇到过并发问题,或者在面试中被问到,所以需要详细说明原因。比如JDK1.7扩容时的transfer方法,多线程同时操作链表,导致节点指向混乱,形成环形链表,进而死循环。这个得结合源码步骤分析,比如Entry的next指针被修改的顺序。 对于JDK1.8,虽然解决了死循环,但put操作时如果没有同步,多个线程可能同时计算哈希、找到桶位置,然后覆盖彼此的数据,造成数据丢失。这时候需要说明具体如何覆盖,比如检查到桶为空,然后同时插入。 解决方案的话,用户可能想知道如何避免这些问题,比如使用ConcurrentHashMap或者Collections.synchronizedMap,或者改用Hashtable。需要对比同方案的优缺点,比如ConcurrentHashMap的锁分段技术,性能更好。 还要注意引用给出的资料,比如引用1、3、5提到JDK1.7的死循环和数据丢失,引用4和5说明JDK1.8的优化和仍然存在的问题。引用2提到JDK1.8的红黑树改进。需要正确标注引用来源。 用户可能更关注实际应用中的解决方案,所以需要给出明确的建议,比如在高并发下推荐使用ConcurrentHashMap。同时,可能希望了解背后的原理,比如为什么JDK1.8的改动解决了死循环,但仍有数据覆盖。 最后,确保回答结构清晰,分点说明问题、原因和解决方案,并生成相关问题,帮助用户进一步学习。比如问到JDK1.8的优化细节,或者ConcurrentHashMap的实现原理。</think>### Java HashMap线程问题及原因分析 #### 一、JDK1.7中的多线程问题 1. **环形链表与死循环** - **原因**:JDK1.7的扩容方法`transfer()`使用**头插法**迁移链表节点。在多线程并发扩容时,若线程A和线程B同时操作链表,可能导致链表节点引用形成环形结构(例如,线程A的`Entry.next`被线程B修改后指向已迁移的节点)。 - **后果**:后续调用`get()`方法时,若查询的键恰好落在环形链表所在的桶,会触发无限循环,导致CPU占用率飙升[^3][^5]。 - **源码示例**: ```java void transfer(Entry[] newTable) { for (Entry<K,V> e : table) { while (null != e) { Entry<K,V> next = e.next; // 步骤1:保存下一个节点 int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; // 步骤2:头插法插入新表 newTable[i] = e; // 步骤3:更新表头 e = next; // 步骤4:遍历下一个节点 } } } ``` 若两个线程同时执行上述代码,可能导致`e.next`指向错误节点,形成环形链表。 2. **数据丢失** - **原因**:多个线程同时执行扩容操作时,可能因竞争导致部分节点未被正确迁移到新数组,最终被垃圾回收[^1]。 --- #### 二、JDK1.8中的多线程问题 1. **数据覆盖** - **原因**:JDK1.8在`putVal()`方法中,若多个线程同时判断某个桶为空,可能先后写入同的键值对,导致后写入的值覆盖前一个。例如: ```java if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = newNode(hash, key, value, null); // 多个线程可能同时执行此操作 ``` - **后果**:最终只有一个线程的数据被保留,其他数据丢失。 2. **红黑树操作的竞争** - **原因**:JDK1.8在链表转红黑树时,若多个线程同时操作,可能破坏红黑树的平衡性,导致查询结果异常(尽管概率较低)[^2]。 --- #### 三、解决方案 1. **使用线程安全的替代类** - **ConcurrentHashMap**(推荐):JDK1.7采用分段锁,JDK1.8改为CAS+synchronized,保证并发安全[^4]。 - **Hashtable**:通过全表锁实现线程安全,但性能较差。 - **Collections.synchronizedMap()**:对HashMap包装一层同步控制。 2. **避免多线程直接操作HashMap** - 若必须使用HashMap,需通过外部锁(如`synchronized`)保证原子性。 --- #### 四、版本差异对比 | 特性 | JDK1.7 | JDK1.8 | |---------------------|---------------------------|---------------------------------| | 数据结构 | 数组+链表 | 数组+链表+红黑树 | | 插入方式 | 头插法 | 尾插法 | | 扩容问题 | 死循环、数据丢失 | 数据覆盖 | | 优化点 | - | 红黑树优化哈希冲突性能 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值