將hashmap和currenthashmap放一塊進行比較，是因為二者的結構相差不多，只不過後者是執行緒安全的。
首先說hashmap,在jdk1.8之前，hashmap的儲存結構是陣列+鍊錶的形式，可以理解為元素為鍊錶的陣列，當新增乙個kv對，首先計算key的雜湊值，用雜湊值對陣列長度按位與，以此確定插入的位置，若該位置已有元素，則形成鍊錶，同一鍊錶元素的雜湊值相同，當鍊表陣列容量超過初始容量0.75時，將陣列擴大一倍。
由上可以看出，當資料量很大時，每乙個位置的鍊錶會變得很長，而鍊錶的平均查詢長度是n/2，查詢耗時很大。
因此jdk1.8後hashmap的儲存結構更新為桶+鍊錶/紅黑樹的形式，和之前相差不多，只不過在對鍊錶長度的反應上做出了改變，當鍊表長度超過8，鍊錶自動轉化為紅黑樹的形式，當長度小於6，仍為鍊錶，這是因為：紅黑樹的平均查詢長度是log（n），當n=8,平均查詢長度是3，鍊錶平均查詢長度是4，此時才有轉換為紅黑樹的必要。而之所以採用紅黑樹，就是因為紅黑樹查詢效率高（它是個二叉平衡樹）。
那為什麼使用6和8作為鍊錶和紅黑樹的分割？
這是因為鍊錶到紅黑樹的轉化過程十分耗費資源，選擇6和8，而不是7，就是為了避免頻繁增刪資料時，不斷轉換耗費大量資源。
HashMap 底層 原理（JDK 1 8）
原來看過1.7的hashmap底層，1.8更新後也稍微看了一下，沒有進行仔細的總結，今天總結一下1.8底層的原理。本文只討論1.8的底層原理。以下全文為1.8版本的 對於hashmap的資料結構，是老生常談了，面試的時候經常會被問道。底層資料結構為陣列 鍊錶 紅黑樹，儲存的是node節點，紅黑樹是t...
HashMap原始碼分析 JDK1 8
陣列 鍊錶 紅黑樹 陣列儲存元素，當有衝突時，就在該陣列位置形成乙個鍊錶，儲存衝突的元素，當鍊表元素個數大於閾值時，鍊錶就轉換為紅黑樹。transient node table transient int size int threshold final float loadfactor 預設初始容...
HashMap原始碼分析 （JDK1 8
首先，hashmap儲存結構類似於位桶，總體結構是 位桶 鍊錶 紅黑樹，這與之前版本的實現有所改進。常量域預設容量16 static final int default initial capacity 1 4 最大容量2的30次方 static final int maximum capacity...