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語句。

然而這都是我的猜測，我沒有證據。而且讓我追紅黑樹的代碼，也是需要耗費大量時間的事情，我需要快速驗證我的猜測。

我之前dump下來了堆內存信息，我通過jhat 命令生成html的內存信息頁面

然后輸入http://localhost:7000查看

我先找業務代碼中持有這個HashMap的對象，然后點進去查詢內部信息

因為數據都放在table中，點擊Table字段，查看其內容

table中存在唯一的一個TreeNode節點，這肯定是已經變成了紅黑樹了

點進去查看

點擊parent字段信息

0x72745d828與0x72745d7b8兩個TreeNode節點的Parent引用都是對方。

后續打算深入研究一下紅黑樹什么場景會造成這個原因。

最后，無論什么并發場景請別使用HashMap，ConcurrentHashmap大法好

到此這篇關于為什么JDK8中HashMap依然會死循環的文章就介紹到這了,更多相關JDK8 HashMap死循環內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！

原文鏈接：https://blog.csdn.net/qq_33330687/article/details/101479385