java中HashMap在多线程环境下引起CPU100%的问题解决

最近项目中出现了Tomcat占用CPU100%的情况，原以为是代码中出现死循环，后台使用jstack做了dump，发现是系统中不合理使用HashMap导致出现了死循环（注意不是死锁）。

产生这个死循环的根源在于对一个未保护的共享变量 — 一个"HashMap"数据结构的操作。当在所有操作的方法上加了"synchronized"后，一切恢复了正常。

这算jvm的bug吗？应该说不是的，这个现象很早以前就报告出来了（详细见：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457）。Sun的工程师并不认为这是bug，而是建议在这样的场景下应采用"ConcurrentHashMap"，

回复中的原话：

This is a classic symptom of an incorrectly synchronized use of
HashMap. Clearly, the submitters need to use a thread-safe
HashMap. If they upgraded to Java 5, they could just use ConcurrentHashMap.

所以在开发过程中应当注意这点，在多线程的环境下，尽量使用ConcurrentHashMap。

可能出现问题的地方是在扩容的时候

Java代码

void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
Entry[] newTable = new Entry[newCapacity];
transfer(newTable);
table = newTable;
threshold = (int)(newCapacity * loadFactor);
}

这个方法本身没有问题，问题出在transfer(newTable);这个方法是用来移动oldTable里的数据到newTable里。

Java代码

/**
* Transfers all entries from current table to newTable.
*/
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
//(1)
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {
//(2)
Entry<K,V> next = e.next;
int i = indexFor(e.hash, newCapacity);
//(3)
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}

下面分析可能出现的情况，假设原来oldTable里存放a1,a2的hash值是一样的，那么entry链表顺序是：

P1:oldTable[i]->a1->a2->null

P2:oldTable[i]->a1->a2->null

线程P1运行到(1)下面这行时，e=a1(a1.next=a2),继续运行到（2）下面时，next=a2。这个时候切换到线程P2，线程P2执行完这个链表的循环。如果恰a1,a2在新的table中的hash值又是一样的，那么此时的链表顺序是：

主存:newTable[i]->a2->a1->null

注意这个时候，a1,a2连接顺序已经反了。现在cpu重新切回P1，在（3）这行以后：e.next = newTable[i];即：a1.next=newTable[i];

newTable[i]=a1;

e=a2;

开始第二次while循环(e=a2,next=a1)：

a2.next=newTable[i];//也就是a2.next=a1

newTable[i]=a2

e=a1

开始第三次while循环（e=a1,next=null）

a1.next=newTable[i];//也就是a1.next=a2

这个时候a1.next=a2,a2.next=a1,形成回环了，这样就造成了死循环，在get操作的时候next永远不为null，造成死循环。

可以看到很偶然的情况下会出现死循环，不过一旦出现后果是非常严重的，多线程的环境还是应该用ConcurrentHashMap。

java中HashMap在多线程环境下引起CPU100%的问题解决相关推荐

【死链】JDK1.7中HashMap在多线程环境的并发问题源码分析
文章目录一.HashMap在JDK1.7中的并发问题二.死链如何产生? 三.如何解决HashMap并发问题参考文献一.HashMap在JDK1.7中的并发问题在JDK1.7中的HashMap ...
多线程环境下HashMap导致CPU100%
引言昨天早上线上系统开始作业了一段时间以后,突然收到服务器报警,服务器CPU持续占用100%,导致线上系统不能正常使用,我登录服务器top了一下,发现java进程占用cpu400%, 由于前天晚上上 ...
Java多线程之单例模式在多线程环境下的安全问题
Java多线程之单例模式在多线程环境下的安全问题目录: 单例模式基本概念单线程下的单例模式多线程下的单例模式单例模式volatile分析 1. 单例模式基本概念基本概念转载自:单例模式|菜鸟 ...
java基础--java中HashMap原理
java中HashMap原理内推军P21 P22 1.为什么用HashMap? HashMap是一个散列桶(数组和链表),它存储的内容是键值对(key-value)映射HashMap采用了数组和链表 ...
HttpClient在多线程环境下踩坑总结
HttpClient在多线程环境下踩坑总结问题现场在多线程环境下使用HttpClient组件对某个HTTP服务发起请求,运行一段时间之后发现客户端主机CPU利用率呈现出下降趋势,而不是一个稳定的状 ...
java中HashMap、ArrayList、HashSet的存储原理及遍历方式汇总
HashMap类底层存储方式:1. HashMap在JDK1.7之前底层是用数组+链表的方式存储的:在JDK1.8之后底层是用数组+链表+红黑树存储的;2.HashMap里面实现了一个静态内部类En ...
多线程环境下，程序真是危机四伏
姿势在不断的更新迭代, 太卷了. 你管这也叫线程安全? 最近大意了,竟然想将<面试官:实现一个带值变更通知能力的Dictionary>一文中的临界锁只应用到写操作. 内心旁白:读操作又不会 ...
单例模式的5种实现方式，以及在多线程环境下5种创建单例模式的效率
这段时间从头温习设计模式.记载下来,以便自己复习,也分享给大家. [java] view plaincopy package com.iter.devbox.singleton; /** * 饿汉式 ...
flask keras 多线程环境下加载模型
keras 多线程环境下加载模型 Tensor Tensor is not an element of this graph. 问题场景 keras 使用flask 发布深度学习模型服务,模型有一个定 ...

java中HashMap在多线程环境下引起CPU100%的问题解决

java中HashMap在多线程环境下引起CPU100%的问题解决相关推荐

最新文章

热门文章