Java HashMap工做原理深刻探討

時間 2019-11-15

標籤 java hashmap 原理深刻探討欄目 Java 简体版

原文原文鏈接

大部分Java開發者都在使用Map，特別是HashMap。HashMap是一種簡單但強大的方式去存儲和獲取數據。但有多少開發者知道HashMap內部如何工做呢？幾天前，我閱讀了java.util.HashMap的大量源代碼（包括Java 7 和Java 8），來深刻理解這個基礎的數據結構。在這篇文章中，我會解釋java.util.HashMap的實現，描述Java 8實現中添加的新特性，並討論性能、內存以及使用HashMap時的一些已知問題。java

內部存儲

Java HashMap類實現了Map<K, V>接口。這個接口中的主要方法包括：node

V put(K key, V value)
V get(Object key)
V remove(Object key)
Boolean containsKey(Object key)

HashMap使用了一個內部類Entry<K, V>來存儲數據。這個內部類是一個簡單的鍵值對，並帶有額外兩個數據：面試

一個指向其餘入口（譯者注：引用對象）的引用，這樣HashMap能夠存儲相似連接列表這樣的對象。
一個用來表明鍵的哈希值，存儲這個值能夠避免HashMap在每次須要時都從新生成鍵所對應的哈希值。

下面是Entry<K, V>在Java 7下的一部分代碼：數組

static class Entry<K,V> implements Map.Entry<K,V> {
        final K key;
        V value;
        Entry<K,V> next;
        int hash;
…
}

HashMap將數據存儲到多個單向Entry鏈表中（有時也被稱爲桶bucket或者容器orbins）。全部的列表都被註冊到一個Entry數組中（Entry<K, V>[]數組），這個內部數組的默認長度是16。安全

下面這幅圖描述了一個HashMap實例的內部存儲，它包含一個nullable對象組成的數組。每一個對象都鏈接到另一個對象，這樣就構成了一個鏈表。數據結構

全部具備相同哈希值的鍵都會被放到同一個鏈表（桶）中。具備不一樣哈希值的鍵最終可能會在相同的桶中。多線程

當用戶調用 put(K key， V value) 或者 get(Object key) 時，程序會計算對象應該在的桶的索引。而後，程序會迭代遍歷對應的列表，來尋找具備相同鍵的Entry對象（使用鍵的equals()方法）。ide

對於調用get()的狀況，程序會返回值所對應的Entry對象（若是Entry對象存在）。函數

對於調用put(K key, V value)的狀況，若是Entry對象已經存在，那麼程序會將值替換爲新值，不然，程序會在單向鏈表的表頭建立一個新的Entry（從參數中的鍵和值）。性能

桶（鏈表）的索引，是經過map的3個步驟生成的：

首先獲取鍵的散列碼。
程序重複散列碼，來阻止針對鍵的糟糕的哈希函數，由於這有可能會將全部的數據都放到內部數組的相同的索引（桶）上。
程序拿到重複後的散列碼，並對其使用數組長度（最小是1）的位掩碼（bit-mask）。這個操做能夠保證索引不會大於數組的大小。你能夠將其看作是一個通過計算的優化取模函數。

下面是生成索引的源代碼：

// the "rehash" function in JAVA 7 that takes the hashcode of the key
static int hash(int h) {
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}
// the "rehash" function in JAVA 8 that directly takes the key
static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }
// the function that returns the index from the rehashed hash
static int indexFor(int h, int length) {
    return h & (length-1);
}

爲了更有效地工做，內部數組的大小必須是2的冪值。讓咱們看一下爲何：

假設數組的長度是17，那麼掩碼的值就是16（數組長度-1）。16的二進制表示是0…010000，這樣對於任何值H來講，「H & 16」的結果就是16或者0。這意味着長度爲17的數組只能應用到兩個桶上：一個是0，另一個是16，這樣不是頗有效率。可是若是你將數組的長度設置爲2的冪值，例如16，那麼按位索引的工做變成「H & 15」。15的二進制表示是0…001111，索引公式輸出的值能夠從0到15，這樣長度爲16的數組就能夠被充分使用了。例如：

若是H = 952，它的二進制表示是0..01110111000，對應的索引是0…01000 = 8
若是H = 1576，它的二進制表示是0..011000101000，對應的索引是0…01000 = 8
若是H = 12356146，它的二進制表示是0..0101111001000101000110010，對應的索引是0…00010 = 2
若是H = 59843，它的二進制表示是0..01110100111000011，它對應的索引是0…00011 = 3

這種機制對於開發者來講是透明的：若是他選擇一個長度爲37的HashMap，Map會自動選擇下一個大於37的2的冪值（64）做爲內部數組的長度。

自動調整大小

在獲取索引後，get()、put()或者remove()方法會訪問對應的鏈表，來查看針對指定鍵的Entry對象是否已經存在。在不作修改的狀況下，這個機制可能會致使性能問題，由於這個方法須要迭代整個列表來查看Entry對象是否存在。假設內部數組的長度採用默認值16，而你須要存儲2，000,000條記錄。在最好的狀況下，每一個鏈表會有125,000個Entry對象（2,000,000/16）。get()、remove()和put()方法在每一次執行時，都須要進行125,000次迭代。爲了不這種狀況，HashMap能夠增長內部數組的長度，從而保證鏈表中只保留不多的Entry對象。

當你建立一個HashMap時，你能夠經過如下構造函數指定一個初始長度，以及一個loadFactor：

</pre>
public HashMap(int initialCapacity, float loadFactor)
<pre>

若是你不指定參數，那麼默認的initialCapacity的值是16， loadFactor的默認值是0.75。initialCapacity表明內部數組的鏈表的長度。

當你每次使用put(…)方法向Map中添加一個新的鍵值對時，該方法會檢查是否須要增長內部數組的長度。爲了實現這一點，Map存儲了2個數據：

Map的大小：它表明HashMap中記錄的條數。咱們在向HashMap中插入或者刪除值時更新它。
閥值：它等於內部數組的長度*loadFactor，在每次調整內部數組的長度時，該閥值也會同時更新。

在添加新的Entry對象以前，put(…)方法會檢查當前Map的大小是否大於閥值。若是大於閥值，它會建立一個新的數組，數組長度是當前內部數組的兩倍。由於新數組的大小已經發生改變，因此索引函數（就是返回「鍵的哈希值 & (數組長度-1)」的位運算結果）也隨之改變。調整數組的大小會建立兩個新的桶（鏈表），而且將全部現存Entry對象從新分配到桶上。調整數組大小的目標在於下降鏈表的大小，從而下降put()、remove()和get()方法的執行時間。對於具備相同哈希值的鍵所對應的全部Entry對象來講，它們會在調整大小後分配到相同的桶中。可是，若是兩個Entry對象的鍵的哈希值不同，但它們以前在同一個桶上，那麼在調整之後，並不能保證它們依然在同一個桶上。

這幅圖片描述了調整前和調整後的內部數組的狀況。在調整數組長度以前，爲了獲得Entry對象E，Map須要迭代遍歷一個包含5個元素的鏈表。在調整數組長度以後，一樣的get()方法則只須要遍歷一個包含2個元素的鏈表，這樣get()方法在調整數組長度後的運行速度提升了2倍。

線程安全

若是你已經很是熟悉HashMap，那麼你確定知道它不是線程安全的，可是爲何呢？例如假設你有一個Writer線程，它只會向Map中插入已經存在的數據，一個Reader線程，它會從Map中讀取數據，那麼它爲何不工做呢？

由於在自動調整大小的機制下，若是線程試着去添加或者獲取一個對象，Map可能會使用舊的索引值，這樣就不會找到Entry對象所在的新桶。

在最糟糕的狀況下，當2個線程同時插入數據，而2次put()調用會同時出發數組自動調整大小。既然兩個線程在同時修改鏈表，那麼Map有可能在一個鏈表的內部循環中退出。若是你試着去獲取一個帶有內部循環的列表中的數據，那麼get()方法永遠不會結束。

HashTable提供了一個線程安全的實現，能夠阻止上述狀況發生。可是，既然全部的同步的CRUD操做都很是慢。例如，若是線程1調用get(key1)，而後線程2調用get(key2)，線程2調用get(key3)，那麼在指定時間，只能有1個線程能夠獲得它的值，可是3個線程均可以同時訪問這些數據。

從Java 5開始，咱們就擁有一個更好的、保證線程安全的HashMap實現：ConcurrentHashMap。對於ConcurrentMap來講，只有桶是同步的，這樣若是多個線程不使用同一個桶或者調整內部數組的大小，它們能夠同時調用get()、remove()或者put()方法。在一個多線程應用程序中，這種方式是更好的選擇。

鍵的不變性

爲何將字符串和整數做爲HashMap的鍵是一種很好的實現？主要是由於它們是不可變的！若是你選擇本身建立一個類做爲鍵，但不能保證這個類是不可變的，那麼你可能會在HashMap內部丟失數據。

咱們來看下面的用例：

你有一個鍵，它的內部值是「1」。
你向HashMap中插入一個對象，它的鍵就是「1」。
HashMap從鍵（即「1」）的散列碼中生成哈希值。
Map在新建立的記錄中存儲這個哈希值。
你改動鍵的內部值，將其變爲「2」。
鍵的哈希值發生了改變，可是HashMap並不知道這一點（由於存儲的是舊的哈希值）。
你試着經過修改後的鍵獲取相應的對象。
Map會計算新的鍵（即「2」）的哈希值，從而找到Entry對象所在的鏈表（桶）。
狀況1：既然你已經修改了鍵，Map會試着在錯誤的桶中尋找Entry對象，沒有找到。
狀況2：你很幸運，修改後的鍵生成的桶和舊鍵生成的桶是同一個。Map這時會在鏈表中進行遍歷，已找到具備相同鍵的Entry對象。可是爲了尋找鍵，Map首先會經過調用equals()方法來比較鍵的哈希值。由於修改後的鍵會生成不一樣的哈希值（舊的哈希值被存儲在記錄中），那麼Map沒有辦法在鏈表中找到對應的Entry對象。

下面是一個Java示例，咱們向Map中插入兩個鍵值對，而後我修改第一個鍵，並試着去獲取這兩個對象。你會發現從Map中返回的只有第二個對象，第一個對象已經「丟失」在HashMap中：

public class MutableKeyTest {

    public static void main(String[] args) {

        class MyKey {
            Integer i;

            public void setI(Integer i) {
                this.i = i;
            }

            public MyKey(Integer i) {
                this.i = i;
            }

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

            @Override
            public boolean equals(Object obj) {
                if (obj instanceof MyKey) {
                    return i.equals(((MyKey) obj).i);
                } else
                    return false;
            }

        }

        Map<MyKey, String> myMap = new HashMap<>();
        MyKey key1 = new MyKey(1);
        MyKey key2 = new MyKey(2);

        myMap.put(key1, "test " + 1);
        myMap.put(key2, "test " + 2);

        // modifying key1
        key1.setI(3);

        String test1 = myMap.get(key1);
        String test2 = myMap.get(key2);

        System.out.println("test1= " + test1 + " test2=" + test2);

    }

}

上述代碼的輸出是「test1=null test2=test 2」。如咱們指望的那樣，Map沒有能力獲取通過修改的鍵 1所對應的字符串1。

Java 8 中的改進

在Java 8中，HashMap中的內部實現進行了不少修改。的確如此，Java 7使用了1000行代碼來實現，而Java 8中使用了2000行代碼。我在前面描述的大部份內容在Java 8中依然是對的，除了使用鏈表來保存Entry對象。在Java 8中，咱們仍然使用數組，但它會被保存在Node中，Node中包含了和以前Entry對象同樣的信息，而且也會使用鏈表：

下面是在Java 8中Node實現的一部分代碼：

   static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;

那麼和Java 7相比，到底有什麼大的區別呢？好吧，Node能夠被擴展成TreeNode。TreeNode是一個紅黑樹的數據結構，它能夠存儲更多的信息，這樣咱們能夠在O(log(n))的複雜度下添加、刪除或者獲取一個元素。下面的示例描述了TreeNode保存的全部信息：

static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
    final int hash; // inherited from Node<K,V>
    final K key; // inherited from Node<K,V>
    V value; // inherited from Node<K,V>
    Node<K,V> next; // inherited from Node<K,V>
    Entry<K,V> before, after;// inherited from LinkedHashMap.Entry<K,V>
    TreeNode<K,V> parent;
    TreeNode<K,V> left;
    TreeNode<K,V> right;
    TreeNode<K,V> prev;
    boolean red;

紅黑樹是自平衡的二叉搜索樹。它的內部機制能夠保證它的長度老是log(n)，無論咱們是添加仍是刪除節點。使用這種類型的樹，最主要的好處是針對內部表中許多數據都具備相同索引（桶）的狀況，這時對樹進行搜索的複雜度是O(log(n))，而對於鏈表來講，執行相同的操做，複雜度是O(n)。

如你所見，咱們在樹中確實存儲了比鏈表更多的數據。根據繼承原則，內部表中能夠包含Node（鏈表）或者TreeNode（紅黑樹）。Oracle決定根據下面的規則來使用這兩種數據結構：

- 對於內部表中的指定索引（桶），若是node的數目多於8個，那麼鏈表就會被轉換成紅黑樹。

- 對於內部表中的指定索引（桶），若是node的數目小於6個，那麼紅黑樹就會被轉換成鏈表。

這張圖片描述了在Java 8 HashMap中的內部數組，它既包含樹（桶0），也包含鏈表（桶1，2和3）。桶0是一個樹結構是由於它包含的節點大於8個。

內存開銷

JAVA 7

使用HashMap會消耗一些內存。在Java 7中，HashMap將鍵值對封裝成Entry對象，一個Entry對象包含如下信息：

指向下一個記錄的引用
一個預先計算的哈希值（整數）
一個指向鍵的引用
一個指向值的引用

此外，Java 7中的HashMap使用了Entry對象的內部數組。假設一個Java 7 HashMap包含N個元素，它的內部數組的容量是CAPACITY，那麼額外的內存消耗大約是：

sizeOf(integer)* N + sizeOf(reference)* (3*N+C)

其中：

整數的大小是4個字節
引用的大小依賴於JVM、操做系統以及處理器，但一般都是4個字節。

這就意味着內存總開銷一般是16 * N + 4 * CAPACITY字節。

注意：在Map自動調整大小後，CAPACITY的值是下一個大於N的最小的2的冪值。

注意：從Java 7開始，HashMap採用了延遲加載的機制。這意味着即便你爲HashMap指定了大小，在咱們第一次使用put()方法以前，記錄使用的內部數組（耗費4*CAPACITY字節）也不會在內存中分配空間。

JAVA 8

在Java 8實現中，計算內存使用狀況變得複雜一些，由於Node可能會和Entry存儲相同的數據，或者在此基礎上再增長6個引用和一個Boolean屬性（指定是不是TreeNode）。

若是全部的節點都只是Node，那麼Java 8 HashMap消耗的內存和Java 7 HashMap消耗的內存是同樣的。

若是全部的節點都是TreeNode，那麼Java 8 HashMap消耗的內存就變成：

N * sizeOf(integer) + N * sizeOf(boolean) + sizeOf(reference)* (9*N+CAPACITY )

在大部分標準JVM中，上述公式的結果是44 * N + 4 * CAPACITY 字節。

性能問題

非對稱HashMap vs 均衡HashMap

在最好的狀況下，get()和put()方法都只有O(1)的複雜度。可是，若是你不去關心鍵的哈希函數，那麼你的put()和get()方法可能會執行很是慢。put()和get()方法的高效執行，取決於數據被分配到內部數組（桶）的不一樣的索引上。若是鍵的哈希函數設計不合理，你會獲得一個非對稱的分區（無論內部數據的是多大）。全部的put()和get()方法會使用最大的鏈表，這樣就會執行很慢，由於它須要迭代鏈表中的所有記錄。在最壞的狀況下（若是大部分數據都在同一個桶上），那麼你的時間複雜度就會變爲O(n)。

下面是一個可視化的示例。第一張圖描述了一個非對稱HashMap，第二張圖描述了一個均衡HashMap。

在這個非對稱HashMap中，在桶0上運行get()和put()方法會很花費時間。獲取記錄K須要花費6次迭代。

在這個均衡HashMap中，獲取記錄K只須要花費3次迭代。這兩個HashMap存儲了相同數量的數據，而且內部數組的大小同樣。惟一的區別是鍵的哈希函數，這個函數用來將記錄分佈到不一樣的桶上。

下面是一個使用Java編寫的極端示例，在這個示例中，我使用哈希函數將全部的數據放到相同的鏈表（桶），而後我添加了2,000,000條數據。

public class Test {

    public static void main(String[] args) {

        class MyKey {
            Integer i;
            public MyKey(Integer i){
                this.i =i;
            }

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

            @Override
            public boolean equals(Object obj) {
            …
            }

        }
        Date begin = new Date();
        Map <MyKey,String> myMap= new HashMap<>(2_500_000,1);
        for (int i=0;i<2_000_000;i++){
            myMap.put( new MyKey(i), "test "+i);
        }

        Date end = new Date();
        System.out.println("Duration (ms) "+ (end.getTime()-begin.getTime()));
    }
}

個人機器配置是core i5-2500k @ 3.6G，在java 8u40下須要花費超過45分鐘的時間來運行（我在45分鐘後中止了進程）。若是我運行一樣的代碼，可是我使用以下的hash函數：

    @Override
    public int hashCode() {
        int key = 2097152-1;
        return key+2097152*i;
}

運行它須要花費46秒，和以前比，這種方式好不少了！新的hash函數比舊的hash函數在處理哈希分區時更合理，所以調用put()方法會更快一些。若是你如今運行相同的代碼，可是使用下面的hash函數，它提供了更好的哈希分區：

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

如今只須要花費2秒！

我但願你可以意識到哈希函數有多重要。若是在Java 7上面運行一樣的測試，第一個和第二個的狀況會更糟（由於Java 7中的put()方法複雜度是O(n)，而Java 8中的複雜度是O(log(n))。

在使用HashMap時，你須要針對鍵找到一種哈希函數，能夠將鍵擴散到最可能的桶上。爲此，你須要避免哈希衝突。String對象是一個很是好的鍵，由於它有很好的哈希函數。Integer也很好，由於它的哈希值就是它自身的值。

調整大小的開銷

若是你須要存儲大量數據，你應該在建立HashMap時指定一個初始的容量，這個容量應該接近你指望的大小。

若是你不這樣作，Map會使用默認的大小，即16，factorLoad的值是0.75。前11次調用put()方法會很是快，可是第12次（16*0.75）調用時會建立一個新的長度爲32的內部數組（以及對應的鏈表/樹），第13次到第22次調用put()方法會很快，可是第23次（32*0.75）調用時會從新建立（再一次）一個新的內部數組，數組的長度翻倍。而後內部調整大小的操做會在第48次、96次、192次…..調用put()方法時觸發。若是數據量不大，重建內部數組的操做會很快，可是數據量很大時，花費的時間可能會從秒級到分鐘級。經過初始化時指定Map指望的大小，你能夠避免調整大小操做帶來的消耗。

但這裏也有一個缺點：若是你將數組設置的很是大，例如2^28，但你只是用了數組中的2^26個桶，那麼你將會浪費大量的內存（在這個示例中大約是2^30字節）。