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

2021-10-05 15:17:04 字數 519 閱讀 8409

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計算新增元素的位置時,使用的位運算,這是特別高效的運算;另外,hashmap的初始容量是2的n次冪,擴容也是2倍的形式進行擴容,是因為容量是2的n次冪,可以使得新增的元素均勻分布在hashmap中的陣列上,減少hash碰撞,避免形成鍊錶的結構,使得查詢效率降低!

為什麼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為了訪問高效,要盡量較少...