多線程編程(4)之ConcurrentHashMap

一前言

Map 這樣的 Key Value 在軟件開發中是非常經典的結構,常用於在內存中存放數據。本篇主要想討論 ConcurrentHashMap 這樣一個併發容器,在正式開始之前我覺得有必要談談 HashMap,沒有它就不會有後面的 ConcurrentHashMap。

二、HashMap分析

衆所周知 HashMap 底層是基於 數組 + 鏈表 組成的,不過在 jdk1.7 和 1.8 中具體實現稍有不同。

1.7 中的數據結構圖:

先來看看 1.7 中的實現:

這是 HashMap 中比較核心的幾個成員變量;看看分別是什麼意思?

  1. 初始化桶大小,因爲底層是數組,所以這是數組默認的大小。
  2. 桶最大值。
  3. 默認的負載因子(0.75)
  4. table 真正存放數據的數組。
  5. Map 存放數量的大小。
  6. 桶大小,可在初始化時顯式指定。
  7. 負載因子,可在初始化時顯式指定。

重點解釋下負載因子:

由於給定的 HashMap 的容量大小是固定的,比如默認初始化:

 1    public HashMap() {
 2        this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR);
 3    }
 4
 5    public HashMap(int initialCapacity, float loadFactor) {
 6        if (initialCapacity < 0)
 7            throw new IllegalArgumentException("Illegal initial capacity: " +
 8                                               initialCapacity);
 9        if (initialCapacity > MAXIMUM_CAPACITY)
10            initialCapacity = MAXIMUM_CAPACITY;
11        if (loadFactor <= 0 || Float.isNaN(loadFactor))
12            throw new IllegalArgumentException("Illegal load factor: " +
13                                               loadFactor);
14
15        this.loadFactor = loadFactor;
16        threshold = initialCapacity;
17        init();
18    }

給定的默認容量爲 16,負載因子爲 0.75。Map 在使用過程中不斷的往裏面存放數據,當數量達到了 16 * 0.75 = 12 就需要將當前 16 的容量進行擴容,而擴容這個過程涉及到 rehash、複製數據等操作,所以非常消耗性能。

因此通常建議能提前預估 HashMap 的大小最好,儘量的減少擴容帶來的性能損耗。

根據代碼可以看到其實真正存放數據的是:

transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;

這個數組,那麼它又是如何定義的呢?

Entry 是 HashMap 中的一個內部類,從他的成員變量很容易看出:

  • key 就是寫入時的鍵。
  • value 自然就是值。
  • 開始的時候就提到 HashMap 是由數組和鏈表組成,所以這個 next 就是用於實現鏈表結構。
  • hash 存放的是當前 key 的 hashcode。

知曉了基本結構,那來看看其中重要的寫入、獲取函數:

2.1put()方法

 1    public V put(K key, V value) {
 2        if (table == EMPTY_TABLE) {
 3            inflateTable(threshold);
 4        }
 5        if (key == null)
 6            return putForNullKey(value);
 7        int hash = hash(key);
 8        int i = indexFor(hash, table.length);
 9        for (Entry<K,V> e = table[i]; e != null; e = e.next) {
10            Object k;
11            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
12                V oldValue = e.value;
13                e.value = value;
14                e.recordAccess(this);
15                return oldValue;
16            }
17        }
18
19        modCount++;
20        addEntry(hash, key, value, i);
21        return null;
22    }
  • 判斷當前數組是否需要初始化。
  • 如果 key 爲空,則 put 一個空值進去。
  • 根據 key 計算出 hashcode。
  • 根據計算出的 hashcode 定位出所在桶(就是對應的table數組的下標)。
  • 如果桶是一個鏈表則需要遍歷判斷裏面的 hashcode、key 是否和傳入 key 相等,如果相等則進行覆蓋,並返回原來的值。
  • 如果桶是空的,說明當前位置沒有數據存入;新增一個 Entry 對象寫入當前位置。
 1    void addEntry(int hash, K key, V value, int bucketIndex) {
 2        if ((size >= threshold) && (null != table[bucketIndex])) {
 3            resize(2 * table.length);
 4            hash = (null != key) ? hash(key) : 0;
 5            bucketIndex = indexFor(hash, table.length);
 6        }
 7
 8        createEntry(hash, key, value, bucketIndex);
 9    }
10
11    void createEntry(int hash, K key, V value, int bucketIndex) {
12        Entry<K,V> e = table[bucketIndex];
13        table[bucketIndex] = new Entry<>(hash, key, value, e);
14        size++;
15    }

當調用 addEntry 寫入 Entry 時需要判斷是否需要擴容。如果需要就進行兩倍擴充,並將當前的 key 重新 hash 並定位。而在 createEntry 中會將當前位置的桶傳入到新建的桶中,如果當前桶有值就會在位置形成鏈表。

2.2 get()方法

再來看看 get 函數:

 1    public V get(Object key) {
 2        if (key == null)
 3            return getForNullKey();
 4        Entry<K,V> entry = getEntry(key);
 5
 6        return null == entry ? null : entry.getValue();
 7    }
 8
 9    final Entry<K,V> getEntry(Object key) {
10        if (size == 0) {
11            return null;
12        }
13
14        int hash = (key == null) ? 0 : hash(key);
15        for (Entry<K,V> e = table[indexFor(hash, table.length)];
16             e != null;
17             e = e.next) {
18            Object k;
19            if (e.hash == hash &&
20                ((k = e.key) == key || (key != null && key.equals(k))))
21                return e;
22        }
23        return null;
24    }
  • 首先也是根據 key 計算出 hashcode,然後定位到具體的桶中。
  • 判斷該位置是否爲鏈表。
  • 不是鏈表就根據 key、key 的 hashcode 是否相等來返回值。
  • 爲鏈表則需要遍歷直到 key 及 hashcode 相等時候就返回值。
  • 啥都沒取到就直接返回 null 。

以上是JDK1.7的HashMap的實現,不知道 1.7 的實現大家看出需要優化的點沒有?其實一個很明顯的地方就是:

當 Hash 衝突嚴重時,在桶上形成的鏈表會變的越來越長,這樣在查詢時的效率就會越來越低;時間複雜度爲 O(N)

因此 1.8 中重點優化了這個查詢效率。1.8 HashMap 結構圖:

先來看看幾個核心的成員變量:

 1    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
 2
 3    /**
 4     * The maximum capacity, used if a higher value is implicitly specified
 5     * by either of the constructors with arguments.
 6     * MUST be a power of two <= 1<<30.
 7     */
 8    static final int MAXIMUM_CAPACITY = 1 << 30;
 9
10    /**
11     * The load factor used when none specified in constructor.
12     */
13    static final float DEFAULT_LOAD_FACTOR = 0.75f;
14
15    static final int TREEIFY_THRESHOLD = 8;
16
17    transient Node<K,V>[] table;
18
19    /**
20     * Holds cached entrySet(). Note that AbstractMap fields are used
21     * for keySet() and values().
22     */
23    transient Set<Map.Entry<K,V>> entrySet;
24
25    /**
26     * The number of key-value mappings contained in this map.
27     */
28    transient int size;

和 1.7 大體上都差不多,還是有幾個重要的區別:

  • TREEIFY_THRESHOLD 用於判斷是否需要將鏈表轉換爲紅黑樹的閾值。
  • HashEntry 修改爲 Node。

Node 的核心組成其實也是和 1.7 中的 HashEntry 一樣,存放的都是 key value hashcode next 等數據。

2.3 put 方法

看似要比 1.7 的複雜,我們一步步拆解:

  1. 判斷當前桶是否爲空,空的就需要初始化(resize 中會判斷是否進行初始化)。
  2. 根據當前 key 的 hashcode 定位到具體的桶中並判斷是否爲空,爲空表明沒有 Hash 衝突就直接在當前位置創建一個新桶即可。
  3. 如果當前桶有值( Hash 衝突),那麼就要比較當前桶中的 key、key 的 hashcode 與寫入的 key 是否相等,相等就賦值給 e,在第 8 步的時候會統一進行賦值及返回
  4. 如果當前桶爲紅黑樹,那就要按照紅黑樹的方式寫入數據。
  5. 如果是個鏈表,就需要將當前的 key、value 封裝成一個新節點寫入到當前桶的後面(形成鏈表)。
  6. 接着判斷當前鏈表的大小是否大於預設的閾值,大於時就要轉換爲紅黑樹。
  7. 如果在遍歷過程中找到 key 相同時直接退出遍歷。
  8. 如果 e != null 就相當於存在相同的 key,那就需要將值覆蓋
  9. 最後判斷是否需要進行擴容。

2.4 get方法

1    public V get(Object key) {
 2        Node<K,V> e;
 3        return (e = getNode(hash(key), key)) == null ? null : e.value;
 4    }
 5
 6    final Node<K,V> getNode(int hash, Object key) {
 7        Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
 8        if ((tab = table) != null && (n = tab.length) > 0 &&
 9            (first = tab[(n - 1) & hash]) != null) {
10            if (first.hash == hash && // always check first node
11                ((k = first.key) == key || (key != null && key.equals(k))))
12                return first;
13            if ((e = first.next) != null) {
14                if (first instanceof TreeNode)
15                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
16                do {
17                    if (e.hash == hash &&
18                        ((k = e.key) == key || (key != null && key.equals(k))))
19                        return e;
20                } while ((e = e.next) != null);
21            }
22        }
23        return null;
24    }

get 方法看起來就要簡單許多了。

  • 首先將 key hash 之後取得所定位的桶。
  • 如果桶爲空則直接返回 null 。
  • 否則判斷桶的第一個位置(有可能是鏈表、紅黑樹)的 key 是否爲查詢的 key,是就直接返回 value。
  • 如果第一個不匹配,則判斷它的下一個是紅黑樹還是鏈表。
  • 紅黑樹就按照樹的查找方式返回值。
  • 不然就按照鏈表的方式遍歷匹配返回值。

從這兩個核心方法(get/put)可以看出 1.8 中對大鏈表做了優化,修改爲紅黑樹之後查詢效率直接提高到了 O(logn)


但是 HashMap 原有的問題也都存在,比如在併發場景下使用時容易出現死循環:

1final HashMap<String, String> map = new HashMap<String, String>();
2for (int i = 0; i < 1000; i++) {
3    new Thread(new Runnable() {
4        @Override
5        public void run() {
6            map.put(UUID.randomUUID().toString(), "");
7        }
8    }).start();
9}

但是爲什麼呢?簡單分析下。

看過上文的還記得在 HashMap 擴容的時候會調用 resize() 方法,就是這裏的併發操作容易在一個桶上形成環形鏈表;這樣當獲取一個不存在的 key 時,計算出的 index 正好是環形鏈表的下標就會出現死循環。

以下模擬2個線程同時擴容。假設,當前HashMap的空間爲2(臨界值爲1),hashcode分別爲 0 和 1,在散列地址 0 處有元素 A 和 B,這時候要添加元素 C,C 經過hash運算,得到散列地址爲 1,這時候由於超過了臨界值,空間不夠,需要調用 resize方法進行擴容,那麼在多線程條件下,會出現條件競爭,模擬過程如下:

線程一:讀取到當前的 HashMap 情況,在準備擴容時,線程二介入:

線程二:讀取 HashMap,進行擴容

線程一:繼續執行

這個過程爲,先將 A 複製到新的hash表中,然後接着複製 B 到鏈頭(A 的前邊:B.next=A),本來 B.next=null,到此也就結束了(跟線程二一樣的過程),但是,由於線程二擴容的原因,將 B.next=A,所以,這裏繼續複製A,讓 A.next=B,由此,環形鏈表出現:B.next=A; A.next=B。

2.5 遍歷方式

還有一個值得注意的是 HashMap 的遍歷方式,通常有以下幾種:

 1Iterator<Map.Entry<String, Integer>> entryIterator = map.entrySet().iterator();
 2        while (entryIterator.hasNext()) {
 3            Map.Entry<String, Integer> next = entryIterator.next();
 4            System.out.println("key=" + next.getKey() + " value=" + next.getValue());
 5        }
 6
 7Iterator<String> iterator = map.keySet().iterator();
 8        while (iterator.hasNext()){
 9            String key = iterator.next();
10            System.out.println("key=" + key + " value=" + map.get(key));
11
12        }

強烈建議使用第一種 EntrySet 進行遍歷。第一種可以把 key value 同時取出,第二種還得需要通過 key 取一次 value,效率較低。

2.6 總結

簡單總結下 HashMap:無論是 1.7 還是 1.8 其實都能看出 JDK 沒有對它做任何的同步操作,所以併發會出問題,甚至出現死循環導致系統不可用。因此 JDK 推出了專項專用的 ConcurrentHashMap ,該類位於 java.util.concurrent 包下,專門用於解決併發問題。

三、 ConcurrentHashMap

ConcurrentHashMap 同樣也分爲 1.7 、1.8 版,兩者在實現上略有不同。

3.1 1.7版ConcurrentHashMap

先來看看 1.7 的實現,下面是他的結構圖:

如圖所示,是由 Segment 數組、HashEntry 組成,和 HashMap 一樣,仍然是數組加鏈表。

它的核心成員變量:

1    /**
2     * Segment 數組,存放數據時首先需要定位到具體的 Segment 中。
3     */
4    final Segment<K,V>[] segments;
5
6    transient Set<K> keySet;
7    transient Set<Map.Entry<K,V>> entrySet;

Segment 是 ConcurrentHashMap 的一個內部類,主要的組成如下:

 1    static final class Segment<K,V> extends ReentrantLock implements Serializable {
 2
 3        private static final long serialVersionUID = 2249069246763182397L;
 4
 5        // 和 HashMap 中的 HashEntry 作用一樣,真正存放數據的桶
 6        transient volatile HashEntry<K,V>[] table;
 7
 8        transient int count;
 9
10        transient int modCount;
11
12        transient int threshold;
13
14        final float loadFactor;
15
16    }

看看其中 HashEntry 的組成:

和 HashMap 非常類似,唯一的區別就是其中的核心數據如 value ,以及鏈表都是 volatile 修飾的,保證了獲取時的可見性。

原理上來說:ConcurrentHashMap 採用了分段鎖技術,其中 Segment 繼承於 ReentrantLock。不會像 HashTable 那樣不管是 put 還是 get 操作都需要做同步處理,理論上 ConcurrentHashMap 支持 CurrencyLevel (Segment 數組數量)的線程併發。每當一個線程佔用鎖訪問一個 Segment 時,不會影響到其他的 Segment。

3.2 put方法

 1    public V put(K key, V value) {
 2        Segment<K,V> s;
 3        if (value == null)
 4            throw new NullPointerException();
 5        int hash = hash(key);
 6        int j = (hash >>> segmentShift) & segmentMask;
 7        if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
 8             (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
 9            s = ensureSegment(j);
10        return s.put(key, hash, value, false);
11    }

首先是通過 key 定位到 Segment,之後在對應的 Segment 中進行具體的 put。

1        final V put(K key, int hash, V value, boolean onlyIfAbsent) {
 2            HashEntry<K,V> node = tryLock() ? null :
 3                scanAndLockForPut(key, hash, value);
 4            V oldValue;
 5            try {
 6                HashEntry<K,V>[] tab = table;
 7                int index = (tab.length - 1) & hash;
 8                HashEntry<K,V> first = entryAt(tab, index);
 9                for (HashEntry<K,V> e = first;;) {
10                    if (e != null) {
11                        K k;
12                        if ((k = e.key) == key ||
13                            (e.hash == hash && key.equals(k))) {
14                            oldValue = e.value;
15                            if (!onlyIfAbsent) {
16                                e.value = value;
17                                ++modCount;
18                            }
19                            break;
20                        }
21                        e = e.next;
22                    }
23                    else {
24                        if (node != null)
25                            node.setNext(first);
26                        else
27                            node = new HashEntry<K,V>(hash, key, value, first);
28                        int c = count + 1;
29                        if (c > threshold && tab.length < MAXIMUM_CAPACITY)
30                            rehash(node);
31                        else
32                            setEntryAt(tab, index, node);
33                        ++modCount;
34                        count = c;
35                        oldValue = null;
36                        break;
37                    }
38                }
39            } finally {
40                unlock();
41            }
42            return oldValue;
43        }

雖然 HashEntry 中的 value 是用 volatile 關鍵詞修飾的,但是並不能保證併發的原子性,所以 put 操作時仍然需要加鎖處理。

首先第一步的時候會嘗試獲取鎖,如果獲取失敗肯定就有其他線程存在競爭,則利用 scanAndLockForPut() 自旋獲取鎖。

  1. 嘗試自旋獲取鎖。
  2. 如果重試的次數達到了 MAX_SCAN_RETRIES 則改爲阻塞鎖獲取,保證能獲取成功。

再結合圖看看 put 的流程。

  1. 將當前 Segment 中的 table 通過 key 的 hashcode 定位到 HashEntry。
  2. 遍歷該 HashEntry,如果不爲空則判斷傳入的 key 和當前遍歷的 key 是否相等,相等則覆蓋舊的 value
  3. 不爲空則需要新建一個 HashEntry 並加入到 Segment 中,同時會先判斷是否需要擴容。
  4. 最後會解除在 1 中所獲取當前 Segment 的鎖。

3.3 get 方法

 1    public V get(Object key) {
 2        Segment<K,V> s; // manually integrate access methods to reduce overhead
 3        HashEntry<K,V>[] tab;
 4        int h = hash(key);
 5        long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
 6        if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
 7            (tab = s.table) != null) {
 8            for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
 9                     (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
10                 e != null; e = e.next) {
11                K k;
12                if ((k = e.key) == key || (e.hash == h && key.equals(k)))
13                    return e.value;
14            }
15        }
16        return null;
17    }

get 邏輯比較簡單:

只需要將 Key 通過 Hash 之後定位到具體的 Segment ,再通過一次 Hash 定位到具體的元素上。

由於 HashEntry 中的 value 屬性是用 volatile 關鍵詞修飾的,保證了內存可見性,所以每次獲取時都是最新值。

ConcurrentHashMap 的 get 方法是非常高效的,因爲整個過程都不需要加鎖


1.7 已經解決了併發問題,並且能支持 N 個 Segment 這麼多次數的併發,但依然存在 HashMap 在 1.7 版本中的問題。

那就是查詢遍歷鏈表效率太低。因此 1.8 做了一些數據結構上的調整。首先來看下底層的組成結構:

看起來是不是和 1.8 HashMap 結構類似?

其中拋棄了原有的 Segment 分段鎖,而採用了 CAS + synchronized 來保證併發安全性。

也將 1.7 中存放數據的 HashEntry 改爲 Node,但作用都是相同的。其中的 val next 都用了 volatile 修飾,保證了可見性。

3.4 put 方法

重點來看看 put 函數:

  1. 根據 key 計算出 hashcode 
  2. 判斷是否需要進行初始化。
  3. f 即爲當前 key 定位出的 Node,如果爲空表示當前位置可以寫入數據,利用 CAS 嘗試寫入,失敗則自旋保證成功。
  4. 如果當前位置的 hashcode == MOVED == -1,則需要進行擴容。
  5. 如果都不滿足,則利用 synchronized 鎖寫入數據。
  6. 如果數量大於 TREEIFY_THRESHOLD 則要轉換爲紅黑樹。

3.5 get方法

  • 根據計算出來的 hashcode 尋址,如果就在桶上那麼直接返回值。
  • 如果是紅黑樹那就按照樹的方式獲取值。
  • 就不滿足那就按照鏈表的方式遍歷獲取值。

1.8 在 1.7 的數據結構上做了大的改動,採用紅黑樹之後可以保證查詢效率(O(logn)),甚至取消了 ReentrantLock 改爲了 synchronized,這樣可以看出在新版的 JDK 中對 synchronized 優化是很到位的。

3.6總結

看完了整個 HashMap 和 ConcurrentHashMap 在 1.7 和 1.8 中不同的實現方式相信大家對他們的理解應該會更加到位。

其實這塊也是面試的重點內容,通常的套路是:

  1. 談談你理解的 HashMap,講講其中的 get put 過程。
  2. 1.8 做了什麼優化?
  3. 是線程安全的嘛?
  4. 不安全會導致哪些問題?
  5. 如何解決?有沒有線程安全的併發容器?
  6. ConcurrentHashMap 是如何實現的? 1.7、1.8 實現有何不同?爲什麼這麼做?

這一串問題相信大家仔細看完都能懟回面試官。除了面試會問到之外平時的應用其實也蠻多,像之前談到的 Guava 中 Cache 的實現就是利用 ConcurrentHashMap 的思想。

同時也能學習 JDK 作者大牛們的優化思路以及併發解決方案。加油!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章