[翻譯]Java HashMap工作原理

李勝攀發表於2015-09-02
JavaHashMap

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

內部儲存

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

  • 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下的一部分程式碼：

1
2
3
4
5
6
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物件組成的陣列。每個物件都連線到另外一個物件，這樣就構成了一個連結串列。

 

internal_storage_java_hashmap

所有具有相同雜湊值的鍵都會被放到同一個連結串列（桶）中。具有不同雜湊值的鍵最終可能會在相同的桶中。

當使用者呼叫 put(K key， V value) 或者 get(Object key) 時，程式會計算物件應該在的桶的索引。然後，程式會迭代遍歷對應的列表，來尋找具有相同鍵的Entry物件（使用鍵的equals()方法）。

對於呼叫get()的情況，程式會返回值所對應的Entry物件（如果Entry物件存在）。

對於呼叫put(K key, V value)的情況，如果Entry物件已經存在，那麼程式會將值替換為新值，否則，程式會在單向連結串列的表頭建立一個新的Entry（從引數中的鍵和值）。

桶（連結串列）的索引，是通過map的3個步驟生成的：

  • 首先獲取鍵的雜湊碼。
  • 程式重複雜湊碼，來阻止針對鍵的糟糕的雜湊函式，因為這有可能會將所有的資料都放到內部陣列的相同的索引（桶）上。
  • 程式拿到重複後的雜湊碼，並對其使用陣列長度（最小是1）的位掩碼（bit-mask）。這個操作可以保證索引不會大於陣列的大小。你可以將其看做是一個經過計算的優化取模函式。

下面是生成索引的原始碼：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 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：

1
2
3
</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物件的鍵的雜湊值不一樣，但它們之前在同一個桶上，那麼在調整以後，並不能保證它們依然在同一個桶上。

resizing_of_java_hashmap

這幅圖片描述了調整前和調整後的內部陣列的情況。在調整陣列長度之前，為了得到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中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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實現的一部分程式碼：

1
2
3
4
5
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儲存的所有資訊：

1
2
3
4
5
6
7
8
9
10
11
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個，那麼紅黑樹就會被轉換成連結串列。

internal_storage_java8_hashmap

這張圖片描述了在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。

skewed_java_hashmap

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

well_balanced_java_hashmap

在這個均衡HashMap中，獲取記錄K只需要花費3次迭代。這兩個HashMap儲存了相同數量的資料，並且內部陣列的大小一樣。唯一的區別是鍵的雜湊函式，這個函式用來將記錄分佈到不同的桶上。

下面是一個使用Java編寫的極端示例，在這個示例中，我使用雜湊函式將所有的資料放到相同的連結串列（桶），然後我新增了2,000,000條資料。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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函式：

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

執行它需要花費46秒，和之前比，這種方式好很多了！新的hash函式比舊的hash函式在處理雜湊分割槽時更合理，因此呼叫put()方法會更快一些。如果你現在執行相同的程式碼，但是使用下面的hash函式，它提供了更好的雜湊分割槽：

1
2
3
4
@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位元組）。

結論

對於簡單的用例，你沒有必要知道HashMap是如何工作的，因為你不會看到O(1)、O(n)以及O(log(n))之間的區別。但是如果能夠理解這一經常使用的資料結構背後的機制，總是有好處的。另外，對於Java開發者職位來說，這是一道典型的面試問題。

對於大資料量的情況，瞭解HashMap如何工作以及理解鍵的雜湊函式的重要性就變得非常重要。

我希望這篇文章可以幫助你對HashMap的實現有一個深入的理解。

原文連結： coding-geek 翻譯： ImportNew.com - Wing
譯文連結： http://www.importnew.com/16599.html

相關文章