HashMap之節(jié)點刪除

大家一直關(guān)注的都是HashMap如何添加節(jié)點，當節(jié)點數(shù)量大于8的時候轉(zhuǎn)化為紅黑樹，否則使用鏈表等等，但大家是否有看過刪除節(jié)點的處理邏輯呢？ 今天來看看HashMap刪除節(jié)點的神來之筆

問題來源

在查看HashMap源碼時，有個以下字段，在刪除的時候，判斷節(jié)點數(shù)量，最多在小于6的時候，會untreeifying(樹轉(zhuǎn)化為鏈表)，在點擊這個字段時發(fā)現(xiàn)，只有在split()方法中使用，但split()方法在resize()方法中使用，與刪除節(jié)點無關(guān)，遂去翻刪除節(jié)點的代碼邏輯

節(jié)點刪除

通過remove方法，一路進來，找到刪除節(jié)點的地方。如下圖：

我們進入removeTreeNode方法中，代碼如下：

查看方法注釋，里面介紹到：如果節(jié)點太少，就會把當前bin轉(zhuǎn)換成普通bin。不理解注釋沒關(guān)系，我們進入這個方法中唯一有轉(zhuǎn)化的地方。進入untreeify()方法查看下。代碼如下：

噢，第一行看一下，if,else看一下，嗯，這個方法就是獲取返回了一個列表(這些方法都是TreeNode類里面的方法，所以請注意，this就是當前要操作的TreeNode節(jié)點)。到此明白，這個方法就是把紅黑樹轉(zhuǎn)化成鏈表的，那么我的就得分析分析是如何操作的了，而沒有使用到定義的全局變量。

刪除判斷邏輯分析

我們來分析分析上面這個邏輯，進入這個untreeify() 的要求是，root == null, root.right ==null, root.left==null, root.left.left==null四種情況，我們以7個節(jié)點的紅黑樹來分析，A為root節(jié)點。

所以進入這個方法主要有以下幾種情況，我們一種一種的來分析當滿足要求時，節(jié)點的個數(shù)。(這里默認認為知道紅黑樹的5個特點，主要是黑平衡)

當這四種情況都滿足時，我們可以看出最多節(jié)點有如上圖所示個數(shù)，可以為7個。(大于8個不考慮，因為大于8會變成紅黑樹)。

1.　　最多節(jié)點情況：當我們刪除節(jié)點D時，只滿足root.left.left==null這個條件，這棵樹仍可以維持紅黑樹的特點，這時的最大節(jié)點數(shù)為6.

2.　　最少節(jié)點情況：當EFG不存在時，在A,B,C,D中刪除任意一個節(jié)點，都會滿足上述四種規(guī)則中的一種。則存在最少節(jié)點情況，有3個節(jié)點。

以上情況都是會將樹轉(zhuǎn)化成鏈表，此時的節(jié)點是 3<= nodes <=6 ，由此可以看出，當節(jié)點數(shù)在小于6時，是可能轉(zhuǎn)化成鏈表，但不是絕對情況， 所以使用定義的變量(固定數(shù)量6)也不正確。只好通過判斷去動態(tài)獲取節(jié)點數(shù)。

節(jié)點數(shù)量原因分析

為什么在小于6的時候可能轉(zhuǎn)換成鏈表，而在大于8的時候轉(zhuǎn)化成紅黑樹？

主要通過時間查詢節(jié)點分析，紅黑樹的平均查詢時間為 log(n), 而鏈表是O(n)，平均是O(n)/2。

當節(jié)點數(shù)為8時，紅黑樹查詢時間2，鏈表查詢時間是：4, 可以看出來當紅黑樹查詢效率大于了鏈表。(兩個函數(shù)曲線問題，當節(jié)點更多是，比紅黑樹需要的時間更多)

當節(jié)點數(shù)為6時，為什么轉(zhuǎn)換成鏈表，我認為主要時因為節(jié)點數(shù)太少，如果還是用紅黑樹，為了維持紅黑樹的特點，則需要翻轉(zhuǎn)，左旋，右旋，等，更消耗性能。

為什么不是7是轉(zhuǎn)化？

主要是為了給一個過渡，防止頻繁轉(zhuǎn)化。 也如上圖，7個節(jié)點可能正好是一個滿二叉樹。

總結(jié)

以上是生活随笔為你收集整理的java哈希map 删除_HashMap1.8之节点删除分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。