ConcurrentHashMap并發容器
ConcurrentHashMap可以做到讀取數據不加鎖，并且其內部的結構可以讓其在進行寫操作的時候能夠將鎖的粒度保持地盡量地小，不用對整個ConcurrentHashMap加鎖。
ConcurrentHashMap的內部結構
ConcurrentHashMap為了提高本身的并發能力，在內部采用了一個叫做Segment的結構，一個Segment其實就是一個類Hash Table的結構，Segment內部維護了一個鏈表數組，我們用下面這一幅圖來看下ConcurrentHashMap的內部結構：
從上面的結構我們可以了解到，ConcurrentHashMap定位一個元素的過程需要進行兩次Hash操作，第一次Hash定位到Segment，第二次Hash定位到元素所在的鏈表的頭部，因此，這一種結構的帶來的副作用是Hash的過程要比普通的HashMap要長，但是帶來的好處是寫操作的時候可以只對元素所在的Segment進行加鎖即可，不會影響到其他的Segment，這樣，在最理想的情況下，ConcurrentHashMap可以最高同時支持Segment數量大小的寫操作（剛好這些寫操作都非常平均地分布在所有的Segment上），所以，通過這一種結構，ConcurrentHashMap的并發能力可以大大的提高。
Segment
我們再來具體了解一下Segment的數據結構：
|
1
2
3
4
5
6
7
|
static final class Segment<K,V> extends ReentrantLock implements Serializable { transient volatile int count; transient int modCount; transient int threshold; transient volatile HashEntry<K,V>[] table; final float loadFactor;} |
詳細解釋一下Segment里面的成員變量的意義：
- count：Segment中元素的數量
- modCount：對table的大小造成影響的操作的數量（比如put或者remove操作）
- threshold：閾值，Segment里面元素的數量超過這個值依舊就會對Segment進行擴容
- table：鏈表數組，數組中的每一個元素代表了一個鏈表的頭部
- loadFactor：負載因子，用于確定threshold
HashEntry
Segment中的元素是以HashEntry的形式存放在鏈表數組中的，看一下HashEntry的結構：
|
1
2
3
4
5
6
|
static final class HashEntry<K,V> { final K key; final int hash; volatile V value; final HashEntry<K,V> next;} |
可以看到HashEntry的一個特點，除了value以外，其他的幾個變量都是final的，這樣做是為了防止鏈表結構被破壞，出現ConcurrentModification的情況。
ConcurrentHashMap的初始化
下面我們來結合源代碼來具體分析一下ConcurrentHashMap的實現，先看下初始化方法：
|
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 ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) { if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0) throw new IllegalArgumentException(); if (concurrencyLevel > MAX_SEGMENTS) concurrencyLevel = MAX_SEGMENTS; // Find power-of-two sizes best matching arguments int sshift = 0; int ssize = 1; while (ssize < concurrencyLevel) { ++sshift; ssize <<= 1; } segmentShift = 32 - sshift; segmentMask = ssize - 1; this.segments = Segment.newArray(ssize); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; int c = initialCapacity / ssize; if (c * ssize < initialCapacity) ++c; int cap = 1; while (cap < c) cap <<= 1; for (int i = 0; i < this.segments.length; ++i) this.segments[i] = new Segment<K,V>(cap, loadFactor);} |
CurrentHashMap的初始化一共有三個參數，一個initialCapacity，表示初始的容量，一個loadFactor，表示負載參數，最后一個是concurrentLevel，代表ConcurrentHashMap內部的Segment的數量，ConcurrentLevel一經指定，不可改變，后續如果ConcurrentHashMap的元素數量增加導致ConrruentHashMap需要擴容，ConcurrentHashMap不會增加Segment的數量，而只會增加Segment中鏈表數組的容量大小，這樣的好處是擴容過程不需要對整個ConcurrentHashMap做rehash，而只需要對Segment里面的元素做一次rehash就可以了。
整個ConcurrentHashMap的初始化方法還是非常簡單的，先是根據concurrentLevel來new出Segment，這里Segment的數量是不大于concurrentLevel的最大的2的指數，就是說Segment的數量永遠是2的指數個，這樣的好處是方便采用移位操作來進行hash，加快hash的過程。接下來就是根據intialCapacity確定Segment的容量的大小，每一個Segment的容量大小也是2的指數，同樣使為了加快hash的過程。
這邊需要特別注意一下兩個變量，分別是segmentShift和segmentMask，這兩個變量在后面將會起到很大的作用，假設構造函數確定了Segment的數量是2的n次方，那么segmentShift就等于32減去n，而segmentMask就等于2的n次方減一。
ConcurrentHashMap的get操作
前面提到過ConcurrentHashMap的get操作是不用加鎖的，我們這里看一下其實現：
|
1
2
3
4
|
public V get(Object key) { int hash = hash(key.hashCode()); return segmentFor(hash).get(key, hash);} |
看第三行，segmentFor這個函數用于確定操作應該在哪一個segment中進行，幾乎對ConcurrentHashMap的所有操作都需要用到這個函數，我們看下這個函數的實現：
|
1
2
3
|
final Segment<K,V> segmentFor(int hash) { return segments[(hash >>> segmentShift) & segmentMask];} |
這個函數用了位操作來確定Segment，根據傳入的hash值向右無符號右移segmentShift位，然后和segmentMask進行與操作，結合我們之前說的segmentShift和segmentMask的值，就可以得出以下結論：假設Segment的數量是2的n次方，根據元素的hash值的高n位就可以確定元素到底在哪一個Segment中。
在確定了需要在哪一個segment中進行操作以后，接下來的事情就是調用對應的Segment的get方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
V get(Object key, int hash) { if (count != 0) { // read-volatile HashEntry<K,V> e = getFirst(hash); while (e != null) { if (e.hash == hash && key.equals(e.key)) { V v = e.value; if (v != null) return v; return readValueUnderLock(e); // recheck } e = e.next; } } return null;} |
先看第二行代碼，這里對count進行了一次判斷，其中count表示Segment中元素的數量，我們可以來看一下count的定義：
|
1
|
transient volatile int count; |
可以看到count是volatile的，實際上這里里面利用了volatile的語義：
對volatile字段的寫入操作happens-before于每一個后續的同一個字段的讀操作。
因為實際上put、remove等操作也會更新count的值，所以當競爭發生的時候，volatile的語義可以保證寫操作在讀操作之前，也就保證了寫操作對后續的讀操作都是可見的，這樣后面get的后續操作就可以拿到完整的元素內容。
然后，在第三行，調用了getFirst()來取得鏈表的頭部：
|
1
2
3
4
|
HashEntry<K,V> getFirst(int hash) { HashEntry<K,V>[] tab = table; return tab[hash & (tab.length - 1)];} |
同樣，這里也是用位操作來確定鏈表的頭部，hash值和HashTable的長度減一做與操作，最后的結果就是hash值的低n位，其中n是HashTable的長度以2為底的結果。
在確定了鏈表的頭部以后，就可以對整個鏈表進行遍歷，看第4行，取出key對應的value的值，如果拿出的value的值是null，則可能這個key，value對正在put的過程中，如果出現這種情況，那么就加鎖來保證取出的value是完整的，如果不是null，則直接返回value。
ConcurrentHashMap的put操作
看完了get操作，再看下put操作，put操作的前面也是確定Segment的過程，這里不再贅述，直接看關鍵的segment的put方法：
|
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
|
V put(K key, int hash, V value, boolean onlyIfAbsent) { lock(); try { int c = count; if (c++ > threshold) // ensure capacity rehash(); HashEntry<K,V>[] tab = table; int index = hash & (tab.length - 1); HashEntry<K,V> first = tab[index]; HashEntry<K,V> e = first; while (e != null && (e.hash != hash || !key.equals(e.key))) e = e.next; V oldValue; if (e != null) { oldValue = e.value; if (!onlyIfAbsent) e.value = value; } else { oldValue = null; ++modCount; tab[index] = new HashEntry<K,V>(key, hash, first, value); count = c; // write-volatile } return oldValue; } finally { unlock(); }} |
首先對Segment的put操作是加鎖完成的，然后在第五行，如果Segment中元素的數量超過了閾值（由構造函數中的loadFactor算出）這需要進行對Segment擴容，并且要進行rehash，關于rehash的過程大家可以自己去了解，這里不詳細講了。
第8和第9行的操作就是getFirst的過程，確定鏈表頭部的位置。
第11行這里的這個while循環是在鏈表中尋找和要put的元素相同key的元素，如果找到，就直接更新更新key的value，如果沒有找到，則進入21行這里，生成一個新的HashEntry并且把它加到整個Segment的頭部，然后再更新count的值。
ConcurrentHashMap的remove操作
Remove操作的前面一部分和前面的get和put操作一樣，都是定位Segment的過程，然后再調用Segment的remove方法：
|
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
|
V remove(Object key, int hash, Object value) { lock(); try { int c = count - 1; HashEntry<K,V>[] tab = table; int index = hash & (tab.length - 1); HashEntry<K,V> first = tab[index]; HashEntry<K,V> e = first; while (e != null && (e.hash != hash || !key.equals(e.key))) e = e.next; V oldValue = null; if (e != null) { V v = e.value; if (value == null || value.equals(v)) { oldValue = v; // All entries following removed node can stay // in list, but all preceding ones need to be // cloned. ++modCount; HashEntry<K,V> newFirst = e.next; for (HashEntry<K,V> p = first; p != e; p = p.next) newFirst = new HashEntry<K,V>(p.key, p.hash, newFirst, p.value); tab[index] = newFirst; count = c; // write-volatile } } return oldValue; } finally { unlock(); }} |
首先remove操作也是確定需要刪除的元素的位置，不過這里刪除元素的方法不是簡單地把待刪除元素的前面的一個元素的next指向后面一個就完事了，我們之前已經說過HashEntry中的next是final的，一經賦值以后就不可修改，在定位到待刪除元素的位置以后，程序就將待刪除元素前面的那一些元素全部復制一遍，然后再一個一個重新接到鏈表上去，看一下下面這一幅圖來了解這個過程：
假設鏈表中原來的元素如上圖所示，現在要刪除元素3，那么刪除元素3以后的鏈表就如下圖所示：
CopyOnWriteArrayList并發容器
Copy-On-Write簡稱COW，是一種用于程序設計中的優化策略。其基本思路是，從一開始大家都在共享同一個內容，當某個人想要修改這個內容的時候，才會真正把內容Copy出去形成一個新的內容然后再改，這是一種延時懶惰策略。從JDK1.5開始Java并發包里提供了兩個使用CopyOnWrite機制實現的并發容器,它們是CopyOnWriteArrayList和CopyOnWriteArraySet。CopyOnWrite容器非常有用，可以在非常多的并發場景中使用到。
什么是CopyOnWrite容器
CopyOnWrite容器即寫時復制的容器。通俗的理解是當我們往一個容器添加元素的時候，不直接往當前容器添加，而是先將當前容器進行Copy，復制出一個新的容器，然后新的容器里添加元素，添加完元素之后，再將原容器的引用指向新的容器。這樣做的好處是我們可以對CopyOnWrite容器進行并發的讀，而不需要加鎖，因為當前容器不會添加任何元素。所以CopyOnWrite容器也是一種讀寫分離的思想，讀和寫不同的容器。
CopyOnWriteArrayList的實現原理
在使用CopyOnWriteArrayList之前，我們先閱讀其源碼了解下它是如何實現的。以下代碼是向CopyOnWriteArrayList中add方法的實現（向CopyOnWriteArrayList里添加元素），可以發現在添加的時候是需要加鎖的，否則多線程寫的時候會Copy出N個副本出來。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/** * Appends the specified element to the end of this list. * * @param e element to be appended to this list * @return <tt>true</tt> (as specified by {@link Collection#add}) */ public boolean add(E e) { final ReentrantLock lock = this.lock; lock.lock(); try { Object[] elements = getArray(); int len = elements.length; Object[] newElements = Arrays.copyOf(elements, len + 1); newElements[len] = e; setArray(newElements); return true; } finally { lock.unlock(); } } |
讀的時候不需要加鎖，如果讀的時候有多個線程正在向CopyOnWriteArrayList添加數據，讀還是會讀到舊的數據，因為寫的時候不會鎖住舊的CopyOnWriteArrayList。
|
1
2
3
|
public E get(int index) { return get(getArray(), index);} |
JDK中并沒有提供CopyOnWriteMap，我們可以參考CopyOnWriteArrayList來實現一個，基本代碼如下：
|
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
|
import java.util.Collection;import java.util.Map;import java.util.Set; public class CopyOnWriteMap<K, V> implements Map<K, V>, Cloneable { private volatile Map<K, V> internalMap; public CopyOnWriteMap() { internalMap = new HashMap<K, V>(); } public V put(K key, V value) { synchronized (this) { Map<K, V> newMap = new HashMap<K, V>(internalMap); V val = newMap.put(key, value); internalMap = newMap; return val; } } public V get(Object key) { return internalMap.get(key); } public void putAll(Map<? extends K, ? extends V> newData) { synchronized (this) { Map<K, V> newMap = new HashMap<K, V>(internalMap); newMap.putAll(newData); internalMap = newMap; } }} |
實現很簡單，只要了解了CopyOnWrite機制，我們可以實現各種CopyOnWrite容器，并且在不同的應用場景中使用。
CopyOnWrite的應用場景
CopyOnWrite并發容器用于讀多寫少的并發場景。比如白名單，黑名單，商品類目的訪問和更新場景，假如我們有一個搜索網站，用戶在這個網站的搜索框中，輸入關鍵字搜索內容，但是某些關鍵字不允許被搜索。這些不能被搜索的關鍵字會被放在一個黑名單當中，黑名單每天晚上更新一次。當用戶搜索時，會檢查當前關鍵字在不在黑名單當中，如果在，則提示不能搜索。實現代碼如下：
|
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
|
package com.ifeve.book; import java.util.Map; import com.ifeve.book.forkjoin.CopyOnWriteMap; /** * 黑名單服務 * * @author fangtengfei * */public class BlackListServiceImpl { private static CopyOnWriteMap<String, Boolean> blackListMap = new CopyOnWriteMap<String, Boolean>( 1000); public static boolean isBlackList(String id) { return blackListMap.get(id) == null ? false : true; } public static void addBlackList(String id) { blackListMap.put(id, Boolean.TRUE); } /** * 批量添加黑名單 * * @param ids */ public static void addBlackList(Map<String,Boolean> ids) { blackListMap.putAll(ids); } } |
代碼很簡單，但是使用CopyOnWriteMap需要注意兩件事情：
1. 減少擴容開銷。根據實際需要，初始化CopyOnWriteMap的大小，避免寫時CopyOnWriteMap擴容的開銷。
2. 使用批量添加。因為每次添加，容器每次都會進行復制，所以減少添加次數，可以減少容器的復制次數。如使用上面代碼里的addBlackList方法。
CopyOnWrite的缺點
CopyOnWrite容器有很多優點，但是同時也存在兩個問題，即內存占用問題和數據一致性問題。所以在開發的時候需要注意一下。
內存占用問題。因為CopyOnWrite的寫時復制機制，所以在進行寫操作的時候，內存里會同時駐扎兩個對象的內存，舊的對象和新寫入的對象（注意:在復制的時候只是復制容器里的引用，只是在寫的時候會創建新對象添加到新容器里，而舊容器的對象還在使用，所以有兩份對象內存）。如果這些對象占用的內存比較大，比如說200M左右，那么再寫入100M數據進去，內存就會占用300M，那么這個時候很有可能造成頻繁的Yong GC和Full GC。之前我們系統中使用了一個服務由于每晚使用CopyOnWrite機制更新大對象，造成了每晚15秒的Full GC，應用響應時間也隨之變長。
針對內存占用問題，可以通過壓縮容器中的元素的方法來減少大對象的內存消耗，比如，如果元素全是10進制的數字，可以考慮把它壓縮成36進制或64進制。或者不使用CopyOnWrite容器，而使用其他的并發容器，如ConcurrentHashMap。
數據一致性問題。CopyOnWrite容器只能保證數據的最終一致性，不能保證數據的實時一致性。所以如果你希望寫入的的數據，馬上能讀到，請不要使用CopyOnWrite容器。
