關於JDK1.7+中HashMap對紅黑樹場景的思考

背景

在1.7以前的版本，當數組元素較多（幾百、幾千，或者更多）的時候，在這種前提擴容，涉及全量元素的遍歷和座標的從新定位，這個耗時會比較長。這是以前存在的一個弊端吧。那麼引入紅黑樹以後就解決了問題，那是怎麼解決的呢，我說下本身的理解。

過程分析

既然數組擴容致使了變慢，那就是從擴容方向思考，誰決定了擴容呢？負載因子和數組長度。數組長度是resize自動作的，因此對用戶來說這應該是一個關注不到的變量，那就只剩負載因子了。負載因子越大，擴容的頻率就越低。

1. 負載因子較小（小於1）

hash碰撞概率小，當數組元素鏈表長度達到8個的時候纔會轉成紅黑樹，知足這種條件的應該很極端很極端了，與JDK1.7以前的差別其實不大，存在擴容時卡頓。

2. 負載因子較大（大於1）

hash碰撞概率大，因此一個數組元素出現紅黑樹的概率變大，每一個樹的數量也會不少。由於擴容的閾值調的比較大，致使輕易不會擴容，整個hashmap更偏向與一顆顆紅黑樹。擴容就能夠理解爲對紅黑樹的維護，達到了絲般順滑的效果。

總結

根據前面的分析，引入紅黑樹主要好處有2個：

1. 極端狀況下，保證hashmap碰撞過多的元素的高性能操做。
2. 負載因子變大狀況，使hashmap傾向於一個紅黑樹的數組，帶來的好處就是對元素的操做時間複雜度的總體穩定。

本質上仍是得具體場景的權衡，若是數組太大，擴容會致使外部調用超時那就選擇調大負載因子，達到削峯的目的。不然維持之前的用法就能夠了，
完。