免責(zé)聲明
本文夾雜部分筆者個人觀點，如描述有誤，歡迎指正
前言
寫這篇文章，是因為最近研究hashmap源碼的時候，會結(jié)合網(wǎng)上的一些博客來促進(jìn)理解。而關(guān)于紅黑樹和鏈表相互轉(zhuǎn)換這一塊，大部分的文章都會這樣描述：hashmap中定義了兩個常量：
static final int TREEIFY_THRESHOLD = 8;
static final int UNTREEIFY_THRESHOLD = 6;
當(dāng)鏈表元素個數(shù)大于8的時候，就會轉(zhuǎn)換為紅黑樹；當(dāng)紅黑樹元素個數(shù)小于6的時候，就會轉(zhuǎn)換回鏈表。
筆者通過仔細(xì)觀察，發(fā)現(xiàn)這種說法并不嚴(yán)謹(jǐn)。hashMap中確實定義了這兩個常量，但并非簡單通過元素個數(shù)的判斷來進(jìn)行轉(zhuǎn)換。
鏈表轉(zhuǎn)換為紅黑樹
鏈表轉(zhuǎn)換為紅黑樹的最終目的，是為了解決在map中元素過多，hash沖突較大，而導(dǎo)致的讀寫效率降低的問題。在源碼的putVal方法中，有關(guān)紅黑樹結(jié)構(gòu)化的分支為：
//此處遍歷鏈表
for (int binCount = 0; ; ++binCount) {
//遍歷到鏈表最后一個節(jié)點
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
//如果鏈表元素個數(shù)大于等于TREEIFY_THRESHOLD
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
//紅黑樹轉(zhuǎn)換邏輯
treeifyBin(tab, hash);
break;
}
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
即網(wǎng)上所說的，鏈表的長度大于8的時候，就轉(zhuǎn)換為紅黑樹，我們來看看treeifyBin方法：
final void treeifyBin(Node<K,V>[] tab, int hash) {
int n, index; Node<K,V> e;
//先判斷table的長度是否小于 MIN_TREEIFY_CAPACITY (64)
if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
//小于64，則擴(kuò)容
resize();
else if ((e = tab[index = (n - 1) & hash]) != null) {
//否則才將鏈表轉(zhuǎn)換為紅黑樹
TreeNode<K,V> hd = null, tl = null;
do {
TreeNode<K,V> p = replacementTreeNode(e, null);
if (tl == null)
hd = p;
else {
p.prev = tl;
tl.next = p;
}
tl = p;
} while ((e = e.next) != null);
if ((tab[index] = hd) != null)
hd.treeify(tab);
}
}
可以看到在treeifyBin中并不是簡單地將鏈表轉(zhuǎn)換為紅黑樹，而是先判斷table的長度是否大于64，如果小于64，就通過擴(kuò)容的方式來解決，避免紅黑樹結(jié)構(gòu)化。原因呢？筆者個人覺得鏈表長度大于8有兩種情況：
- 1、table長度足夠，hash沖突過多
- 2、hash沒有沖突，但是在計算table下標(biāo)的時候，由于table長度太小，導(dǎo)致很多hash不一致的key計算的下標(biāo)一致
第二種情況是可以用擴(kuò)容的方式來避免的，擴(kuò)容后鏈表長度變短，讀寫效率自然提高。另外，擴(kuò)容相對于轉(zhuǎn)換為紅黑樹的好處在于可以保證數(shù)據(jù)結(jié)構(gòu)更簡單。
由此可見并不是鏈表長度超過8就一定會轉(zhuǎn)換成紅黑樹，而是先嘗試擴(kuò)容
紅黑樹轉(zhuǎn)換為鏈表
基本思想是當(dāng)紅黑樹中的元素減少并小于一定數(shù)量時，會切換回鏈表。而元素減少有兩種情況：
- 1、調(diào)用map的remove方法刪除元素
hashMap的remove方法，會進(jìn)入到removeNode方法，找到要刪除的節(jié)點，并判斷node類型是否為treeNode，然后進(jìn)入刪除紅黑樹節(jié)點邏輯的removeTreeNode方法中，該方法有關(guān)解除紅黑樹結(jié)構(gòu)的分支如下：
//判斷是否要解除紅黑樹的條件
if (root == null || root.right == null ||
(rl = root.left) == null || rl.left == null) {
tab[index] = first.untreeify(map); // too small
return;
}
可以看到，此處并沒有利用到網(wǎng)上所說的，當(dāng)節(jié)點數(shù)小于UNTREEIFY_THRESHOLD時才轉(zhuǎn)換，而是通過紅黑樹根節(jié)點及其子節(jié)點是否為空來判斷。而滿足該條件的最大紅黑樹結(jié)構(gòu)如下：
節(jié)點數(shù)為10，大于 UNTREEIFY_THRESHOLD（6），但是根據(jù)該方法的邏輯判斷，是需要轉(zhuǎn)換為鏈表的
- 2、resize的時候，對紅黑樹進(jìn)行了拆分
resize的時候，判斷節(jié)點類型，如果是鏈表，則將鏈表拆分，如果是TreeNode，則執(zhí)行TreeNode的split方法分割紅黑樹，而split方法中將紅黑樹轉(zhuǎn)換為鏈表的分支如下：
//在這之前的邏輯是將紅黑樹每個節(jié)點的hash和一個bit進(jìn)行&運算，
//根據(jù)運算結(jié)果將樹劃分為兩棵紅黑樹，lc表示其中一棵樹的節(jié)點數(shù)
if (lc <= UNTREEIFY_THRESHOLD)
tab[index] = loHead.untreeify(map);
else {
tab[index] = loHead;
if (hiHead != null) // (else is already treeified)
loHead.treeify(tab);
}
這里才用到了 UNTREEIFY_THRESHOLD 的判斷，當(dāng)紅黑樹節(jié)點元素小于等于6時，才調(diào)用untreeify方法轉(zhuǎn)換回鏈表
總結(jié)
- 1、hashMap并不是在鏈表元素個數(shù)大于8就一定會轉(zhuǎn)換為紅黑樹，而是先考慮擴(kuò)容，擴(kuò)容達(dá)到默認(rèn)限制后才轉(zhuǎn)換
- 2、hashMap的紅黑樹不一定小于6的時候才會轉(zhuǎn)換為鏈表，而是只有在resize的時候才會根據(jù) UNTREEIFY_THRESHOLD 進(jìn)行轉(zhuǎn)換。（原因？不太明白hhh）
