JDK8的HashMap为何仍可能出现死循环现象?
- 内容介绍
- 文章标签
- 相关推荐
本文共计545个文字,预计阅读时间需要3分钟。
JDK8的HashMap可能存在死循环问题。虽然听说JDK8之后已经解决了HashMap的扩容死循环问题,但HashMap本身线程不安全,不会导致服务器load升高问题。实际情况并非如此。年轻人可能听说。
JDK8中HashMap依然会死循环!
是否你听说过JDK8之后HashMap已经解决的扩容死循环的问题,虽然HashMap依然说线程不安全,但是不会造成服务器load飙升的问题。
然而事实并非如此。少年可曾了解一种红黑树成环的场景,=v=
今日在查看监控时候发现,某一台机器load飙升
感觉问题不对劲,ssh大法登陆机器,top,top -Hp,jstack,jmap四连击保存下来堆栈,cpu使用最高的线程,内存信息准备分析。
首先查看使用最耗费cpu的线程堆栈信息
cat stack | grep -i 34670 -C10 --color
我勒个去,HashMap,猜测八成死循环了,但是我们使用的JDK8,在8中通过栈封闭的链表替换,解决了扩容死循环的问题。疑惑,继续往下看。
根据堆栈信息,root方法是问题所在,点开HashMap源码
好嘛,load飙高,代码有个for语句,我觉得铁定死循环了,看代码情况只可能是两个红黑树节点的父亲节点相互引用才可以导致无法走出这个for语句。
然而这都是我的猜测,我没有证据。而且让我追红黑树的代码,也是需要耗费大量时间的事情,我需要快速验证我的猜测。
本文共计545个文字,预计阅读时间需要3分钟。
JDK8的HashMap可能存在死循环问题。虽然听说JDK8之后已经解决了HashMap的扩容死循环问题,但HashMap本身线程不安全,不会导致服务器load升高问题。实际情况并非如此。年轻人可能听说。
JDK8中HashMap依然会死循环!
是否你听说过JDK8之后HashMap已经解决的扩容死循环的问题,虽然HashMap依然说线程不安全,但是不会造成服务器load飙升的问题。
然而事实并非如此。少年可曾了解一种红黑树成环的场景,=v=
今日在查看监控时候发现,某一台机器load飙升
感觉问题不对劲,ssh大法登陆机器,top,top -Hp,jstack,jmap四连击保存下来堆栈,cpu使用最高的线程,内存信息准备分析。
首先查看使用最耗费cpu的线程堆栈信息
cat stack | grep -i 34670 -C10 --color
我勒个去,HashMap,猜测八成死循环了,但是我们使用的JDK8,在8中通过栈封闭的链表替换,解决了扩容死循环的问题。疑惑,继续往下看。
根据堆栈信息,root方法是问题所在,点开HashMap源码
好嘛,load飙高,代码有个for语句,我觉得铁定死循环了,看代码情况只可能是两个红黑树节点的父亲节点相互引用才可以导致无法走出这个for语句。
然而这都是我的猜测,我没有证据。而且让我追红黑树的代码,也是需要耗费大量时间的事情,我需要快速验证我的猜测。

