HashMap多线程死循环问题

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

主要是多线程同时put时,如果同时触发了rehash操作,会导致HashMap中的链表中出现循环节点,进而使得后面get的时候,会死循环。【关于什么是rehash,读者可以自行去google了】

本文主要参考了:http://coolshell.cn/articles/9606.html,测试数据也一样。

测试代码:

import java.util.HashMap;

public class HashMapInfiniteLoop {

	private static HashMap<Integer, Integer> map = new HashMap<Integer, Integer>(2,0.75f);
	public static void main(String[] args) {
		map.put(5, 55);

		new Thread("Thread1") {
			public void run() {
				map.put(7, 77);
				System.out.println(map);
			};
		}.start();
		new Thread("Thread2") {
			public void run() {
				map.put(3, 33);
				System.out.println(map);
			};
		}.start();

	}

}

其中,map初始化为一个长度为2的数组,loadFactor=0.75,threshold=2*0.75=1,也就是说当put第二个key的时候,map就需要进行rehash:

下面开始调试运行测试程序

(1)首先使Thread1和Thread2都停在run()的第一行:

此时map的内容为:

(2)Thread1调试进入JDK源代码,停在HashMap.transfer()方法内第一行,切换到Thread2,也停在HashMap.transfer()方法内第一行

此时map的内容为:

(3)切换到Thread1,停在HashMap.transfer()方法内477行【src[j] = null;】;切换到Thread2,也停在477行

(4)切换回Thread1,继续执行,停在图中480行:【int i = indexFor(e.hash, newCapacity);】

此时map内容没变,只是添加了代码中的e、next指针:

(5)切换回Thread2,直接把Thread2执行完毕:

此时map的内容为:

(6)切换回Thread1,回到transfer()方法中:

此时从调试信息中还可以清晰地看出map的内容:{5=55, 7=77, 3=33}

此时map形如:

(7)继续Thread1中的do-while循环,第一次循环过后,依旧【停在480行】:

(8)第二次循环过后,依旧【停在480行】:

(8)第二次循环过后,e已经为null,跳出循环:

(9)离开transfer()方法,回到resize方法中,将newTable赋值给map.table,此时在查看map,默认的toString()方法已经在死循环了

至此,map中数组索引位置为3的链表上已经成功的出现了环,再对map做索引位置为3的get操作,就会死循环在这里,CPU成功到达100%。

比如,调用map.get(11)时,即会引起死循环。

而且,map中还丢失了元素,(5,55)已经不再map中了。

时间: 2024-10-20 07:28:16

HashMap多线程死循环问题的相关文章

多线程下HashMap的死循环问题

多线程下[HashMap]的问题: 1.多线程put操作后,get操作导致死循环. 2.多线程put非NULL元素后,get操作得到NULL值. 3.多线程put操作,导致元素丢失. 本次主要关注[HashMap]-死循环问题. 为何出现死循环? 大家都知道,HashMap采用链表解决Hash冲突,具体的HashMap的分析可以参考一下Java集合---HashMap源码剖析 的分析.因为是链表结构,那么就很容易形成闭合的链路,这样在循环的时候只要有线程对这个HashMap进行get操作就会产生

图解集合5:不正确地使用HashMap引发死循环及元素丢失

问题引出 前一篇文章讲解了HashMap的实现原理,讲到了HashMap不是线程安全的.那么HashMap在多线程环境下又会有什么问题呢? 几个月前,公司项目的一个模块在线上运行的时候出现了死循环,死循环的代码就卡在HashMap的get方法上.尽管最终发现不是因为HashMap导致的,但却让我重视了HashMap在多线程环境下会引发死循环的这个问题,下面先用一段代码简单模拟出HashMap的死循环: public class HashMapThread extends Thread { pri

集合(五)不正确地使用HashMap引发死循环及元素丢失

前一篇文章讲解了HashMap的实现原理,讲到了HashMap不是线程安全的.那么HashMap在多线程环境下又会有什么问题呢? 几个月前,公司项目的一个模块在线上运行的时候出现了死循环,死循环的代码就卡在HashMap的get方法上.尽管最终发现不是因为HashMap导致的,但却让我重视了HashMap在多线程环境下会引发死循环的这个问题,下面先用一段代码简单模拟出HashMap的死循环: public class HashMapThread extends Thread { private

Java - HashMap 多线程安全解析

HashMap多线程并发问题分析 多线程put后可能导致get死循环 从前我们的Java代码因为一些原因使用了HashMap这个东西,但是当时的程序是单线程的,一切都没有问题.后来,我们的程序性能有问题,所以需要变成多线程的,于是,变成多线程后到了线上,发现程序经常占了100%的CPU,查看堆栈,你会发现程序都Hang在了HashMap.get()这个方法上了,重启程序后问题消失.但是过段时间又会来.而且,这个问题在测试环境里可能很难重现. 我们简单的看一下我们自己的代码,我们就知道HashMa

JDK1.7源码分析【集合】HashMap的死循环

前言 在JDK1.7&1.8源码对比分析[集合]HashMap中我们遗留了一个问题:为什么HashMap在调用resize() 方法时会出现死循环?这篇文章就通过JDK1.7的源码来分析并解释这个问题. 如下,并发场景下使用HashMap造成Race Condition,从而导致死循环,现象是CPU 100%被占用. final HashMap<String, String> map = new HashMap<String, String>(); for (int i =

深入理解JAVA集合系列三:HashMap的死循环解读

由于在公司项目中偶尔会遇到HashMap死循环造成CPU100%,重启后问题消失,隔一段时间又会反复出现.今天在这里来仔细剖析下多线程情况下HashMap所带来的问题: 1.多线程put操作后,get操作导致死循环. 2.多线程put非null元素后,get操作得到null值. 3.多线程put操作,导致元素丢失. 死循环场景重现 下面我用一段简单的DEMO模拟HashMap死循环: 1 public class Test extends Thread 2 { 3 static HashMap<

HashMap(1) 死循环

今天看代码,想到去年发生的HashMap发生的CPU使用率100%的事件,转载下当时看的三个比较不错的博客(非常推荐) 参考:http://coolshell.cn/articles/9606.html   http://github.thinkingbar.com/hashmap-analysis/ http://developer.51cto.com/art/201102/246431.htm 在淘宝内网里看到同事发了贴说了一个CPU被100%的线上故障,并且这个事发生了很多次,原因是在Ja

Java HashMap的死循环

在淘宝内网里看到同事发了贴说了一个CPU被100%的线上故障,并且这个事发生了很多次,原因是在Java语言在并发情况下使用HashMap造成Race Condition,从而导致死循环.这个事情我4.5年前也经历过,本来觉得没什么好写的,因为Java的HashMap是非线程安全的,所以在并发下必然出现问题.但是,我发现近几年,很多人都经历过这个事(在网上查“HashMap Infinite Loop”可以看到很多人都在说这个事)所以,觉得这个是个普遍问题,需要写篇疫苗文章说一下这个事,并且给大家

HashMap多线程并发问题分析

原文出处: 陶邦仁 并发问题的症状 多线程put后可能导致get死循环 从前我们的Java代码因为一些原因使用了HashMap这个东西,但是当时的程序是单线程的,一切都没有问题.后来,我们的程序性能有问题,所以需要变成多线程的,于是,变成多线程后到了线上,发现程序经常占了100%的CPU,查看堆栈,你会发现程序都Hang在了HashMap.get()这个方法上了,重启程序后问题消失.但是过段时间又会来.而且,这个问题在测试环境里可能很难重现. 我们简单的看一下我们自己的代码,我们就知道HashM