轉自：Aaron_濤
連結：blog.csdn.net/qq_33330687/article/details/101479385
是否你聽說過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大法好