JDK8中HashMap依然會死循環(huán)！
是否你聽說過JDK8之后HashMap已經(jīng)解決的擴(kuò)容死循環(huán)的問題，雖然HashMap依然說線程不安全，但是不會造成服務(wù)器load飆升的問題。
然而事實并非如此。少年可曾了解一種紅黑樹成環(huán)的場景，=v=
今日在查看監(jiān)控時候發(fā)現(xiàn)，某一臺機(jī)器load飆升
感覺問題不對勁，ssh大法登陸機(jī)器，top，top -Hp,jstack，jmap四連擊保存下來堆棧，cpu使用最高的線程，內(nèi)存信息準(zhǔn)備分析。
首先查看使用最耗費(fèi)cpu的線程堆棧信息
cat stack | grep -i 34670 -C10 --color
我勒個去，HashMap，猜測八成死循環(huán)了，但是我們使用的JDK8，在8中通過棧封閉的鏈表替換，解決了擴(kuò)容死循環(huán)的問題。疑惑，繼續(xù)往下看。
根據(jù)堆棧信息，root方法是問題所在，點(diǎn)開HashMap源碼
好嘛，load飆高，代碼有個for語句，我覺得鐵定死循環(huán)了，看代碼情況只可能是兩個紅黑樹節(jié)點(diǎn)的父親節(jié)點(diǎn)相互引用才可以導(dǎo)致無法走出這個for語句。
然而這都是我的猜測，我沒有證據(jù)。而且讓我追紅黑樹的代碼，也是需要耗費(fèi)大量時間的事情，我需要快速驗證我的猜測。
我之前dump下來了堆內(nèi)存信息，我通過jhat 命令生成html的內(nèi)存信息頁面
然后輸入http://localhost:7000查看
我先找業(yè)務(wù)代碼中持有這個HashMap的對象，然后點(diǎn)進(jìn)去查詢內(nèi)部信息
因為數(shù)據(jù)都放在table中，點(diǎn)擊Table字段，查看其內(nèi)容
table中存在唯一的一個TreeNode節(jié)點(diǎn)，這肯定是已經(jīng)變成了紅黑樹了
點(diǎn)進(jìn)去查看
點(diǎn)擊parent字段信息
0x72745d828與0x72745d7b8兩個TreeNode節(jié)點(diǎn)的Parent引用都是對方。
后續(xù)打算深入研究一下紅黑樹什么場景會造成這個原因。
最后，無論什么并發(fā)場景請別使用HashMap，ConcurrentHashmap大法好
到此這篇關(guān)于為什么JDK8中HashMap依然會死循環(huán)的文章就介紹到這了,更多相關(guān)JDK8 HashMap死循環(huán)內(nèi)容請搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！
原文鏈接：https://blog.csdn.net/qq_33330687/article/details/101479385
