為什麼HashMap中煉表長度超過8會轉換成紅黑樹

hashmap在jdk1.8之後引入了紅黑樹的概念，表示若桶中鍊錶元素超過8時，會自動轉化成紅黑樹；若桶中元素小於等於6時，樹結構還原成鍊錶形式。

原因：紅黑樹的平均查詢長度是log(n)，長度為8，查詢長度為log(8)=3，鍊錶的平均查詢長度為n/2，當長度為8時，平均查詢長度為8/2=4，這才有轉換成樹的必要；鍊錶長度如果是小於等於6，6/2=3，雖然速度也很快的，但是轉化為樹結構和生成樹的時間並不會太短。

還有選擇6和8的原因是：

中間有個差值7可以防止鍊錶和樹之間頻繁的轉換。假設一下，如果設計成煉表個數超過8則鍊錶轉換成樹結構，鍊錶個數小於8則樹結構轉換成鍊錶，如果乙個hashmap不停的插入、刪除元素，鍊錶個數在8左右徘徊，就會頻繁的發生樹轉鍊錶、鍊錶轉樹，效率會很低。

hashmap在jdk1.8之後引入了紅黑樹的概念，表示若桶中鍊錶元素超過8時，會自動轉化成紅黑樹；若桶中元素小於等於6時，樹結構還原成鍊錶形式。

原因：紅黑樹的平均查詢長度是log(n)，長度為8，查詢長度為log(8)=3，鍊錶的平均查詢長度為n/2，當長度為8時，平均查詢長度為8/2=4，這才有轉換成樹的必要；鍊錶長度如果是小於等於6，6/2=3，雖然速度也很快的，但是轉化為樹結構和生成樹的時間並不會太短。

還有選擇6和8的原因是：

中間有個差值7可以防止鍊錶和樹之間頻繁的轉換。假設一下，如果設計成煉表個數超過8則鍊錶轉換成樹結構，鍊錶個數小於8則樹結構轉換成鍊錶，如果乙個hashmap不停的插入、刪除元素，鍊錶個數在8左右徘徊，就會頻繁的發生樹轉鍊錶、鍊錶轉樹，效率會很低。

為什麼HashMap中煉表長度超過8會轉換成紅黑樹

hashmap在jdk1.8之後引入了紅黑樹的概念，表示若桶中鍊錶元素超過8時，會自動轉化成紅黑樹 若桶中元素小於等於6時，樹結構還原成鍊錶形式。原因 紅黑樹的平均查詢長度是log n 長度為8，查詢長度為log 8 3，鍊錶的平均查詢長度為n 2，當長度為8時，平均查詢長度為8 2 4，這才有轉換...

對於HashMap為什麼要使用陣列加鍊表的個人思考

問題的源頭 hashmap資料結構是？陣列加鍊表，1.8增加了紅黑樹，那麼為什麼？陣列的特點查詢快，增刪慢，鍊錶查詢慢，增刪快，陣列加鍊表是折中方案 其實這種描述並不準確，因為在使用hashmap的時候陣列插入並不慢，而鍊錶增刪快的特點也沒有發揮出來，因為每次put都需要遍歷一遍判斷key值是否相等...

HashMap的長度為什麼要是2的n次方

hashmap訪問時，都需要計算當前key應該對應entry陣列哪個元素，即計算陣列下標 演算法如下 returns index for hash code h.staticintindexfor inth,intlength returnh length 1 hashmap為了訪問高效，要盡量較少...