hashMap實現原理

時間  2020-02-13
標籤 hashmap 實現 原理 简体版
原文   原文鏈接

HashMap概述

HashMap是基於哈希表的Map接口的非同步實現。此實現提供全部可選的映射操做，並容許使用null值和null鍵。此類不保證映射的順序，特別是它不保證該順序恆久不變。java

內部實現

HashMap的數據結構（字段）

在Java編程語言中，最基本的結構就是兩種，一個是數組，另一個是模擬指針（引用），全部的數據結構均可以用這兩個基本結構來構造的，HashMap也不例外。HashMap其實是一個「鏈表散列」的數據結構，即數組和鏈表的結構，可是在jdk1.8裏 
加入了紅黑樹的實現，當鏈表的長度大於8時，轉換爲紅黑樹的結構。node

這裏寫圖片描述

從上圖中能夠看出，java中HashMap採用了鏈地址法。鏈地址法，簡單來講，就是數組加鏈表的結合。在每一個數組元素上都一個鏈表結構，當數據被Hash後，獲得數組下標，把數據放在對應下標元素的鏈表上。程序員

複製代碼; "複製代碼")算法

*/編程

static class Node<K,V> implements Map.Entry<K,V> { final int hash;//用於定位數組索引的位置
    final K key;
    V value;
    Node<K,V> next;//鏈表的下一個Node

Node(int hash, K key, V value, Node<K,V> next) { this.hash = hash; this.key = key; this.value = value; this.next = next;數組

}

複製代碼; "複製代碼")緩存

Node是HashMap的一個內部類，實現了Map.Entry接口，本質是就是一個映射(鍵值對)。安全

有時兩個key會定位到相同的位置，表示發生了Hash碰撞。固然Hash算法計算結果越分散均勻，Hash碰撞的機率就越小，map的存取效率就會越高。數據結構

HashMap類中有一個很是重要的字段，就是 Node[] table，即哈希桶數組，明顯它是一個Node的數組。多線程

若是哈希桶數組很大，即便較差的Hash算法也會比較分散，若是哈希桶數組數組很小，即便好的Hash算法也會出現較多碰撞，因此就須要在空間成本和時間成本之間權衡，其實就是在根據實際狀況肯定哈希桶數組的大小，並在此基礎上設計好的hash算法減小Hash碰撞。那麼經過什麼方式來控制map使得Hash碰撞的機率又小，哈希桶數組（Node[] table）佔用空間又少呢？答案就是好的Hash算法和擴容機制。

在理解Hash和擴容流程以前，咱們得先了解下HashMap的幾個字段。從HashMap的默認構造函數源碼可知，構造函數就是對下面幾個字段進行初始化，源碼以下：

int threshold; // 所能容納的key-value對極限
final float loadFactor; // 負載因子
int modCount; int size;

首先，Node[] table的初始化長度length(默認值是16)，Load factor爲負載因子(默認值是0.75)，threshold是HashMap所能容納的最大數據量的Node(鍵值對)個數。threshold = length * Load factor。也就是說，在數組定義好長度以後，負載因子越大，所能容納的鍵值對個數越多。

結合負載因子的定義公式可知，threshold就是在此Load factor和length(數組長度)對應下容許的最大元素數目，超過這個數目就從新resize(擴容)，擴容後的HashMap容量是以前容量的兩倍。默認的負載因子0.75是對空間和時間效率的一個平衡選擇，建議你們不要修改，除非在時間和空間比較特殊的狀況下，若是內存空間不少而又對時間效率要求很高，能夠下降負載因子Load factor的值；相反，若是內存空間緊張而對時間效率要求不高，能夠增長負載因子loadFactor的值，這個值能夠大於1。

size這個字段其實很好理解，就是HashMap中實際存在的鍵值對數量。注意和table的長度length、容納最大鍵值對數量threshold的區別。而modCount字段主要用來記錄HashMap內部結構發生變化的次數，主要用於迭代的快速失敗。強調一點，內部結構發生變化指的是結構發生變化，例如put新鍵值對，可是某個key對應的value值被覆蓋不屬於結構變化。

在HashMap中，哈希桶數組table的長度length大小必須爲2的n次方(必定是合數)，這是一種很是規的設計，常規的設計是把桶的大小設計爲素數。相對來講素數致使衝突的機率要小於合數，具體證實能夠參考http://blog.csdn.net/liuqiyao_01/article/details/14475159，Hashtable初始化桶大小爲11，就是桶大小設計爲素數的應用（Hashtable擴容後不能保證仍是素數）。HashMap採用這種很是規設計，主要是爲了在取模和擴容時作優化，同時爲了減小衝突，HashMap定位哈希桶索引位置時，也加入了高位參與運算的過程。

這裏存在一個問題，即便負載因子和Hash算法設計的再合理，也免不了會出現拉鍊過長的狀況，一旦出現拉鍊過長，則會嚴重影響HashMap的性能。因而，在JDK1.8版本中，對數據結構作了進一步的優化，引入了紅黑樹。而當鏈表長度太長（默認超過8）時，鏈表就轉換爲紅黑樹，利用紅黑樹快速增刪改查的特色提升HashMap的性能，其中會用到紅黑樹的插入、刪除、查找等算法

方法：

1 肯定哈希桶數組索引位置

代碼實現：

複製代碼; "複製代碼")

//方法一：
static final int hash(Object key) { //jdk1.8 & jdk1.7

int h; // h = key.hashCode() 爲第一步 取hashCode值 // h ^ (h >>> 16)  爲第二步 高位參與運算
 return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);

} //方法二：
static int indexFor(int h, int length) { //jdk1.7的源碼，jdk1.8沒有這個方法，可是實現原理同樣的

return h & (length-1);  //第三步 取模運算

}

複製代碼; "複製代碼")

這裏的Hash算法本質上就是三步：取key的hashCode值、高位運算、取模運算。

對於任意給定的對象，只要它的hashCode()返回值相同，那麼程序調用方法一所計算獲得的Hash碼值老是相同的。咱們首先想到的就是把hash值對數組長度取模運算，這樣一來，元素的分佈相對來講是比較均勻的。可是，模運算的消耗仍是比較大的，在HashMap中是這樣作的：調用方法二來計算該對象應該保存在table數組的哪一個索引處。

這個方法很是巧妙，它經過h & (table.length -1)來獲得該對象的保存位，而HashMap底層數組的長度老是2的n次方，這是HashMap在速度上的優化。當length老是2的n次方時，h& (length-1)運算等價於對length取模，也就是h%length，可是&比%具備更高的效率。

在JDK1.8的實現中，優化了高位運算的算法，經過hashCode()的高16位異或低16位實現的：(h = k.hashCode()) ^ (h >>> 16)，主要是從速度、功效、質量來考慮的，這麼作能夠在數組table的length比較小的時候，也能保證考慮到高低Bit都參與到Hash的計算中，同時不會有太大的開銷。

下面舉例說明下，n爲table的長度。

這裏寫圖片描述

2 HashMap的put方法實現

put函數大體的思路爲：

  1. 對key的hashCode()作hash，而後再計算index;
  2. 若是沒碰撞直接放到bucket裏；
  3. 若是碰撞了，以鏈表的形式存在buckets後；
  4. 若是碰撞致使鏈表過長(大於等於TREEIFY_THRESHOLD)，就把鏈表轉換成紅黑樹；
  5. 若是節點已經存在就替換old value(保證key的惟一性)
  6. 若是bucket滿了(超過load factor*current capacity)，就要resize。

具體代碼實現以下：

複製代碼; "複製代碼")

public V put(K key, V value) { return putVal(hash(key), key, value, false, true);

} /\*\* \*生成hash的方法 \*/
static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
} final V putVal(int hash, K key, V value, boolean onlyIfAbsent,boolean evict) {
    Node<K,V>\[\] tab; Node<K,V> p; int n, i; //判斷table是否爲空，
    if ((tab = table) == null || (n = tab.length) == 0)
        n \= (tab = resize()).length;//建立一個新的table數組，而且獲取該數組的長度 //根據鍵值key計算hash值獲得插入的數組索引i，若是table\[i\]==null，直接新建節點添加 
    if ((p = tab\[i = (n - 1) & hash\]) == null)
        tab\[i\] \= newNode(hash, key, value, null); else {//若是對應的節點存在
        Node<K,V> e; K k; //判斷table\[i\]的首個元素是否和key同樣，若是相同直接覆蓋value
        if (p.hash == hash && ((k \= p.key) == key || (key != null && key.equals(k))))
            e \= p; //判斷table\[i\] 是否爲treeNode，即table\[i\] 是不是紅黑樹，若是是紅黑樹，則直接在樹中插入鍵值對
        else if (p instanceof TreeNode)
            e \= ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); // 該鏈爲鏈表
        else { //遍歷table\[i\]，判斷鏈表長度是否大於TREEIFY\_THRESHOLD(默認值爲8)，大於8的話把鏈表轉換爲紅黑樹，在紅黑樹中執行插入操做，不然進行鏈表的插入操做；遍歷過程當中若發現key已經存在直接覆蓋value便可；
            for (int binCount = 0; ; ++binCount) { if ((e = p.next) == null) {
                    p.next \= newNode(hash, key, value, null); if (binCount >= TREEIFY\_THRESHOLD - 1) // -1 for 1st

treeifyBin(tab, hash); break;

} if (e.hash == hash && ((k \= e.key) == key || (key != null && key.equals(k)))) break;
                p \= e;
            }
        } // 寫入
        if (e != null) { // existing mapping for key
            V oldValue = e.value; if (!onlyIfAbsent || oldValue == null)
                e.value \= value;
            afterNodeAccess(e); return oldValue;
        }
    } ++modCount; // 插入成功後，判斷實際存在的鍵值對數量size是否超多了最大容量threshold，若是超過，進行擴容
    if (++size > threshold)
        resize();
    afterNodeInsertion(evict); return null;
}

複製代碼; "複製代碼")

3 HashMap的get方法實現

思路以下：

bucket裏的第一個節點，直接命中；

若是有衝突，則經過key.equals(k)去查找對應的entry 

若爲樹，則在樹中經過key.equals(k)查找，O(logn)； 

若爲鏈表，則在鏈表中經過key.equals(k)查找，O(n)。

複製代碼; "複製代碼")

public V get(Object key) {

Node<K,V> e; return (e = getNode(hash(key), key)) == null ? null : e.value;
} final Node<K,V> getNode(int hash, Object key) {
    Node<K,V>\[\] tab; Node<K,V> first, e; int n; K k; if ((tab = table) != null && (n = tab.length) > 0 && (first \= tab\[(n - 1) & hash\]) != null) { // 直接命中
        if (first.hash == hash && // 每次都是校驗第一個node
            ((k = first.key) == key || (key != null && key.equals(k)))) return first; // 未命中
        if ((e = first.next) != null) { // 在樹中獲取
            if (first instanceof TreeNode) return ((TreeNode<K,V>)first).getTreeNode(hash, key); // 在鏈表中獲取
            do { if (e.hash == hash && ((k \= e.key) == key || (key != null && key.equals(k)))) return e;
            } while ((e = e.next) != null);
        }
    } return null;
}

複製代碼; "複製代碼")

4 擴容機制

擴容(resize)就是從新計算容量，向HashMap對象裏不停的添加元素，而HashMap對象內部的數組沒法裝載更多的元素時，對象就須要擴大數組的長度，以便能裝入更多的元素。固然Java裏的數組是沒法自動擴容的，方法是使用一個新的數組代替已有的容量小的數組，就像咱們用一個小桶裝水，若是想裝更多的水，就得換大水桶。

咱們分析下resize的源碼，鑑於JDK1.8融入了紅黑樹，較複雜，爲了便於理解咱們仍然使用JDK1.7的代碼，好理解一些，本質上區別不大，具體區別後文再說。

複製代碼; "複製代碼")

void resize(int newCapacity) { //傳入新的容量

Entry\[\] oldTable = table;    //引用擴容前的Entry數組
 int oldCapacity = oldTable.length; if (oldCapacity == MAXIMUM\_CAPACITY) {  //擴容前的數組大小若是已經達到最大(2^30)了
      threshold = Integer.MAX\_VALUE; //修改閾值爲int的最大值(2^31-1)，這樣之後就不會擴容了
     return;
 }

 Entry\[\] newTable \= new Entry\[newCapacity\];  //初始化一個新的Entry數組
 transfer(newTable);                         //！！將數據轉移到新的Entry數組裏
 table = newTable;                           //HashMap的table屬性引用新的Entry數組

threshold = (int)(newCapacity * loadFactor);//修改閾值
}

複製代碼; "複製代碼")

這裏就是使用一個容量更大的數組來代替已有的容量小的數組，transfer()方法將原有Entry數組的元素拷貝到新的Entry數組裏。

複製代碼; "複製代碼")

void transfer(Entry[] newTable) {

Entry\[\] src \= table;                   //src引用了舊的Entry數組
  int newCapacity = newTable.length; for (int j = 0; j < src.length; j++) { //遍歷舊的Entry數組
      Entry<K,V> e = src\[j\];             //取得舊Entry數組的每一個元素
      if (e != null) {
          src\[j\] \= null;//釋放舊Entry數組的對象引用（for循環後，舊的Entry數組再也不引用任何對象）
          do {
              Entry<K,V> next = e.next; int i = indexFor(e.hash, newCapacity); //！！從新計算每一個元素在數組中的位置
             e.next = newTable\[i\]; //標記\[1\]
             newTable\[i\] = e;      //將元素放在數組上
             e = next;             //訪問下一個Entry鏈上的元素
         } while (e != null);
     }
 }

}

複製代碼; "複製代碼")

newTable[i]的引用賦給了e.next，也就是使用了單鏈表的頭插入方式，同一位置上新元素總會被放在鏈表的頭部位置；這樣先放在一個索引上的元素終會被放到Entry鏈的尾部(若是發生了hash衝突的話），這一點和Jdk1.8有區別，下文詳解。在舊數組中同一條Entry鏈上的元素，經過從新計算索引位置後，有可能被放到了新數組的不一樣位置上。

下面舉個例子說明下擴容過程。假設了咱們的hash算法就是簡單的用key mod 一下表的大小（也就是數組的長度）。其中的哈希桶數組table的size=2， 因此key = 三、七、5，put順序依次爲 五、七、3。在mod 2之後都衝突在table[1]這裏了。這裏假設負載因子 loadFactor=1，即當鍵值對的實際大小size 大於 table的實際大小時進行擴容。接下來的三個步驟是哈希桶數組 resize成4，而後全部的Node從新rehash的過程。

這裏寫圖片描述

下面咱們講解下JDK1.8作了哪些優化。通過觀測能夠發現，咱們使用的是2次冪的擴展(指長度擴爲原來2倍)，因此，元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置。看下圖能夠明白這句話的意思，n爲table的長度，圖（a）表示擴容前的key1和key2兩種key肯定索引位置的示例，圖（b）表示擴容後key1和key2兩種key肯定索引位置的示例，其中hash1是key1對應的哈希與高位運算結果。

hashMap 1.8 哈希算法例圖1

元素在從新計算hash以後，由於n變爲2倍，那麼n-1的mask範圍在高位多1bit(紅色)，所以新的index就會發生這樣的變化：

hashMap 1.8 哈希算法例圖2

所以，咱們在擴充HashMap的時候，不須要像JDK1.7的實現那樣從新計算hash，只須要看看原來的hash值在新增的那個bit位是1仍是0就行了，是0的話索引沒變，是1的話索引變成「原索引+oldCap」，能夠看看下圖爲16擴充爲32的resize示意圖：

jdk1.8 hashMap擴容例圖

這個設計確實很是的巧妙，既省去了從新計算hash值的時間，並且同時，因爲新增的1bit是0仍是1能夠認爲是隨機的，所以resize的過程，均勻的把以前的衝突的節點分散到新的bucket了。這一塊就是JDK1.8新增的優化點。有一點注意區別，JDK1.7中rehash的時候，舊鏈表遷移新鏈表的時候，若是在新表的數組索引位置相同，則鏈表元素會倒置，可是從上圖能夠看出，JDK1.8不會倒置。有興趣的同窗能夠研究下JDK1.8的resize源碼，寫的很贊，以下:

複製代碼; "複製代碼")

final Node<K,V>[] resize() {

Node<K,V>\[\] oldTab = table; int oldCap = (oldTab == null) ? 0 : oldTab.length; int oldThr = threshold; int newCap, newThr = 0; if (oldCap > 0) { // 超過最大值就再也不擴充了，就只好隨你碰撞去吧
    if (oldCap >= MAXIMUM\_CAPACITY) {
        threshold \= Integer.MAX\_VALUE; return oldTab;
    } // 沒超過最大值，就擴充爲原來的2倍
    else if ((newCap = oldCap << 1) < MAXIMUM\_CAPACITY && oldCap \>= DEFAULT\_INITIAL\_CAPACITY)
        newThr \= oldThr << 1; // double threshold

} else if (oldThr > 0) // initial capacity was placed in threshold

newCap = oldThr; else {               // zero initial threshold signifies using defaults
    newCap = DEFAULT\_INITIAL\_CAPACITY;
    newThr \= (int)(DEFAULT\_LOAD\_FACTOR \* DEFAULT\_INITIAL\_CAPACITY);
} // 計算新的resize上限
if (newThr == 0) { float ft = (float)newCap \* loadFactor;
    newThr \= (newCap < MAXIMUM\_CAPACITY && ft < (float)MAXIMUM\_CAPACITY ? (int)ft : Integer.MAX\_VALUE);
}
threshold \= newThr;
@SuppressWarnings({"rawtypes","unchecked"})
    Node<K,V>\[\] newTab = (Node<K,V>\[\])new Node\[newCap\];
table \= newTab; if (oldTab != null) { // 把每一個bucket都移動到新的buckets中
    for (int j = 0; j < oldCap; ++j) {
        Node<K,V> e; if ((e = oldTab\[j\]) != null) {
            oldTab\[j\] \= null; if (e.next == null)
                newTab\[e.hash & (newCap - 1)\] = e; else if (e instanceof TreeNode)
                ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); else { // preserve order
                Node<K,V> loHead = null, loTail = null;
                Node<K,V> hiHead = null, hiTail = null;
                Node<K,V> next; do {
                    next \= e.next; // 原索引  oldCap - 1:   0 1111     oldCap : 1 0000       判斷 key的 hash值的那一位是否爲1分爲兩類
                    if ((e.hash & oldCap) == 0) { if (loTail == null)
                            loHead \= e; else loTail.next \= e;
                        loTail \= e;
                    } // 原索引+oldCap
                    else { if (hiTail == null)
                            hiHead \= e; else hiTail.next \= e;
                        hiTail \= e;
                    }
                } while ((e = next) != null); // 原索引放到bucket裏
                if (loTail != null) {
                    loTail.next \= null;
                    newTab\[j\] \= loHead;
                } // 原索引+oldCap放到bucket裏
                if (hiTail != null) {
                    hiTail.next \= null;
                    newTab\[j \+ oldCap\] = hiHead;
                }
            }
        }
    }
} return newTab;

}

複製代碼; "複製代碼")

線程安全性

在多線程使用場景中，應該儘可能避免使用線程不安全的HashMap，而使用線程安全的ConcurrentHashMap。那麼爲何說HashMap是線程不安全的，下面舉例子說明在併發的多線程使用場景中使用HashMap可能形成死循環。代碼例子以下(便於理解，仍然使用JDK1.7的環境)：

複製代碼; "複製代碼")

public class HashMapInfiniteLoop { private static HashMap<Integer,String> map = new HashMap<Integer,String>(2，0.75f); public static void main(String[] args) {

map.put(5， "C"); new Thread("Thread1") { public void run() {  
            map.put(7, "B");  
            System.out.println(map);  
        };  
    }.start(); new Thread("Thread2") { public void run() {  
            map.put(3, "A);

System.out.println(map);

};  
    }.start();        
}

}

複製代碼; "複製代碼")

其中，map初始化爲一個長度爲2的數組，loadFactor=0.75，threshold=2*0.75=1，也就是說當put第二個key的時候，map就須要進行resize。

經過設置斷點讓線程1和線程2同時debug到transfer方法(3.3小節代碼塊)的首行。注意此時兩個線程已經成功添加數據。放開thread1的斷點至transfer方法的「Entry next = e.next;」 這一行；而後放開線程2的的斷點，讓線程2進行resize。結果以下圖。

注意，Thread1的 e 指向了key(3)，而next指向了key(7)，其在線程二rehash後，指向了線程二重組後的鏈表。

線程一被調度回來執行，先是執行 newTalbe[i] = e， 而後是e = next，致使了e指向了key(7)，而下一次循環的next = e.next致使了next指向了key(3)。

e.next = newTable[i] 致使 key(3).next 指向了 key(7)。注意：此時的key(7).next 已經指向了key(3)， 環形鏈表就這樣出現了。

因而，當咱們用線程一調用map.get(11)時，悲劇就出現了——Infinite Loop。

JDK1.8與JDK1.7的性能對比

HashMap中，若是key通過hash算法得出的數組索引位置所有不相同，即Hash算法很是好，那樣的話，getKey方法的時間複雜度就是O(1)，若是Hash算法技術的結果碰撞很是多，假如Hash算極其差，全部的Hash算法結果得出的索引位置同樣，那樣全部的鍵值對都集中到一個桶中，或者在一個鏈表中，或者在一個紅黑樹中，時間複雜度分別爲O(n)和O(lgn)。 鑑於JDK1.8作了多方面的優化，整體性能優於JDK1.7，下面咱們從兩個方面用例子證實這一點。

Hash較均勻的狀況

爲了便於測試，咱們先寫一個類Key，以下：

複製代碼; "複製代碼")

public class HashMapInfiniteLoop { private static HashMap<Integer,String> map = new HashMap<Integer,String>(2，0.75f); public static void main(String[] args) {

map.put(5， "C"); new Thread("Thread1") { public void run() {  
            map.put(7, "B");  
            System.out.println(map);  
        };  
    }.start(); new Thread("Thread2") { public void run() {  
            map.put(3, "A);

System.out.println(map);

};  
    }.start();        
}

}

複製代碼; "複製代碼")

這個類複寫了equals方法，而且提供了至關好的hashCode函數，任何一個值的hashCode都不會相同，由於直接使用value當作hashcode。爲了不頻繁的GC，我將不變的Key實例緩存了起來，而不是一遍一遍的建立它們。代碼以下：

複製代碼; "複製代碼")

public class Keys { public static final int MAX_KEY = 10_000_000; private static final Key[] KEYS_CACHE = new Key[MAX_KEY]; static { for (int i = 0; i < MAX_KEY; ++i) {

KEYS\_CACHE\[i\] \= new Key(i);
    }
} public static Key of(int value) { return KEYS\_CACHE\[value\];
}

}

複製代碼; "複製代碼")

如今開始咱們的試驗，測試須要作的僅僅是，建立不一樣size的HashMap（一、十、100、......10000000），屏蔽了擴容的狀況，代碼以下：

複製代碼; "複製代碼")

static void test(int mapSize) {

HashMap<Key, Integer> map = new HashMap<Key,Integer>(mapSize); for (int i = 0; i < mapSize; ++i) {
        map.put(Keys.of(i), i);
    } long beginTime = System.nanoTime(); //獲取納秒
    for (int i = 0; i < mapSize; i++) {
        map.get(Keys.of(i));
    } long endTime = System.nanoTime();
    System.out.println(endTime \- beginTime);
} public static void main(String\[\] args) { for(int i=10;i<= 1000 0000;i\*= 10){
        test(i);
    }
}

複製代碼; "複製代碼")

在測試中會查找不一樣的值，而後度量花費的時間，爲了計算getKey的平均時間，咱們遍歷全部的get方法，計算總的時間，除以key的數量，計算一個平均值，主要用來比較，絕對值可能會受不少環境因素的影響。結果以下：

經過觀測測試結果可知，JDK1.8的性能要高於JDK1.7 15%以上，在某些size的區域上，甚至高於100%。由於Hash算法較均勻，JDK1.8引入的紅黑樹效果不明顯，下面咱們看看Hash不均勻的的狀況。

Hash極不均勻的狀況

假設咱們又一個很是差的Key，它們全部的實例都返回相同的hashCode值。這是使用HashMap最壞的狀況。代碼修改以下：

`class Key implements Comparable<Key> {

//...

@Override
public int hashCode() {
    return 1;
}

}`

仍然執行main方法，得出的結果以下表所示：

從表中結果中可知，隨着size的變大，JDK1.7的花費時間是增加的趨勢，而JDK1.8是明顯的下降趨勢，而且呈現對數增加穩定。當一個鏈表太長的時候，HashMap會動態的將它替換成一個紅黑樹，這話的話會將時間複雜度從O(n)降爲O(logn)。hash算法均勻和不均勻所花費的時間明顯也不相同，這兩種狀況的相對比較，能夠說明一個好的hash算法的重要性。

測試環境：處理器爲2.2 GHz Intel Core i7，內存爲16 GB 1600 MHz DDR3，SSD硬盤，使用默認的JVM參數，運行在64位的OS X 10.10.1上。

小結

(1) 擴容是一個特別耗性能的操做，因此當程序員在使用HashMap的時候，估算map的大小，初始化的時候給一個大體的數值，避免map進行頻繁的擴容。

(2) 負載因子是能夠修改的，也能夠大於1，可是建議不要輕易修改，除非狀況很是特殊。

(3) HashMap是線程不安全的，不要在併發的環境中同時操做HashMap，建議使用ConcurrentHashMap。

(4) JDK1.8引入紅黑樹大程度優化了HashMap的性能。

(5) 還沒升級JDK1.8的，如今開始升級吧。HashMap的性能提高僅僅是JDK1.8的冰山一角。

總結

咱們如今能夠回答開始的幾個問題，加深對HashMap的理解：

  1. 何時會使用HashMap？他有什麼特色？

    是基於Map接口的實現，存儲鍵值對時，它能夠接收null的鍵值，是非同步的，HashMap存儲着Entry(hash, key, value, next)對象。

  2. 你知道HashMap的工做原理嗎？

    經過hash的方法，經過put和get存儲和獲取對象。存儲對象時，咱們將K/V傳給put方法時，它調用hashCode計算hash從而獲得bucket位置，進一步存儲，HashMap會根據當前bucket的佔用狀況自動調整容量(超過Load Facotr則resize爲原來的2倍)。獲取對象時，咱們將K傳給get，它調用hashCode計算hash從而獲得bucket位置，並進一步調用equals()方法肯定鍵值對。若是發生碰撞的時候，Hashmap經過鏈表將產生碰撞衝突的元素組織起來，在Java 8中，若是一個bucket中碰撞衝突的元素超過某個限制(默認是8)，則使用紅黑樹來替換鏈表，從而提升速度。

  3. 你知道get和put的原理嗎？equals()和hashCode()的都有什麼做用？

    經過對key的hashCode()進行hashing，並計算下標( n-1 & hash)，從而得到buckets的位置。若是產生碰撞，則利用key.equals()方法去鏈表或樹中去查找對應的節點

  4. 你知道hash的實現嗎？爲何要這樣實現？

    在Java 1.8的實現中，是經過hashCode()的高16位異或低16位實現的：(h = k.hashCode()) ^ (h >>> 16)，主要是從速度、功效、質量來考慮的，這麼作能夠在bucket的n比較小的時候，也能保證考慮到高低bit都參與到hash的計算中，同時不會有太大的開銷。

  5. 若是HashMap的大小超過了負載因子(load factor)定義的容量，怎麼辦？

    若是超過了負載因子(默認0.75)，則會從新resize一個原來長度兩倍的HashMap，而且從新調用hash方法。 
    關於Java集合的小抄中是這樣描述的： 
    以Entry[]數組實現的哈希桶數組，用Key的哈希值取模桶數組的大小可獲得數組下標。 
    插入元素時，若是兩條Key落在同一個桶(好比哈希值1和17取模16後都屬於第一個哈希桶)，Entry用一個next屬性實現多個Entry以單向鏈表存放，後入桶的Entry將next指向桶當前的Entry。 
    查找哈希值爲17的key時，先定位到第一個哈希桶，而後以鏈表遍歷桶裏全部元素，逐個比較其key值。 
    當Entry數量達到桶數量的75%時(不少文章說使用的桶數量達到了75%，但看代碼不是)，會成倍擴容桶數組，並從新分配全部原來的Entry，因此這裏也最好有個預估值。 
    取模用位運算(hash & (arrayLength-1))會比較快，因此數組的大小永遠是2的N次方， 你隨便給一個初始值好比17會轉爲32。默認第一次放入元素時的初始值是16。 
    iterator()時順着哈希桶數組來遍歷，看起來是個亂序。

  6. 當兩個對象的hashcode相同會發生什麼？

    由於hashcode相同，因此它們的bucket位置相同，‘碰撞’會發生。由於HashMap使用鏈表存儲對象，這個Entry(包含有鍵值對的Map.Entry對象)會存儲在鏈表中。

  7. 若是兩個鍵的hashcode相同，你如何獲取值對象？

    找到bucket位置以後，會調用keys.equals()方法去找到鏈表中正確的節點，最終找到要找的值對象。所以，設計HashMap的key類型時，若是使用不可變的、聲明做final的對象，而且採用合適的equals()和hashCode()方法的話，將會減小碰撞的發生，提升效率。不可變性可以緩存不一樣鍵的hashcode，這將提升整個獲取對象的速度，使用String，Interger這樣的wrapper類做爲鍵是很是好的選擇

  8. 若是HashMap的大小超過了負載因子(load factor)定義的容量，怎麼辦？

    默認的負載因子大小爲0.75，也就是說，當一個map填滿了75%的bucket時候，和其它集合類(如ArrayList等)同樣，將會建立原來HashMap大小的兩倍的bucket數組，來從新調整map的大小，並將原來的對象放入新的bucket數組中。這個過程叫做rehashing，由於它調用hash方法找到新的bucket位置

  9. 你瞭解從新調整HashMap大小存在什麼問題嗎？

    當從新調整HashMap大小的時候，確實存在條件競爭，由於若是兩個線程都發現HashMap須要從新調整大小了，它們會同時試着調整大小。在調整大小的過程當中，存儲在鏈表中的元素的次序會反過來，由於移動到新的bucket位置的時候，HashMap並不會將元素放在鏈表的尾部，而是放在頭部，這是爲了不尾部遍歷(tail traversing)。若是條件競爭發生了，那麼就死循環了。所以在併發環境下，咱們使用CurrentHashMap來替代HashMap

  10. 爲何String, Interger這樣的wrapper類適合做爲鍵？

    由於String是不可變的，也是final的，並且已經重寫了equals()和hashCode()方法了。其餘的wrapper類也有這個特色。不可變性是必要的，由於爲了要計算hashCode()，就要防止鍵值改變，若是鍵值在放入時和獲取時返回不一樣的hashcode的話，那麼就不能從HashMap中找到你想要的對象。不可變性還有其餘的優勢如線程安全。若是你能夠僅僅經過將某個field聲明成final就能保證hashCode是不變的，那麼請這麼作吧。由於獲取對象的時候要用到equals()和hashCode()方法，那麼鍵對象正確的重寫這兩個方法是很是重要的。若是兩個不相等的對象返回不一樣的hashcode的話，那麼碰撞的概率就會小些，這樣就能提升HashMap的性能
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程