今天我們介紹一下ConcurrentHashMap在JDK1.8中的實現。
基本結構

ConcurrentHashMap在1.8中的實現，相比於1.7的版本基本上全部都變掉了。首先，取消了Segment分段鎖的數據結構，取而代之的是數組+鏈表（紅黑樹）的結構。而對於鎖的粒度，調整為對每個數組元素加鎖（Node）。然後是定位節點的hash算法被簡化了，這樣帶來的弊端是Hash沖突會加劇。因此在鏈表節點數量大於8時，會將鏈表轉化為紅黑樹進行存儲。這樣一來，查詢的時間復雜度就會由原先的O(n)變為O(logN)。下面是其基本結構：

相關屬性

1. private transient volatile int sizeCtl;

sizeCtl用於table[]的初始化和擴容操作，不同值的代表狀態如下：

• -1：table[]正在初始化。
• -N：表示有N-1個線程正在進行擴容操作。

非負情況：

1. 如果table[]未初始化，則表示table需要初始化的大小。
2. 如果初始化完成，則表示table[]擴容的閥值，默認是table[]容量的0.75 倍。

1. private static finalint DEFAULT_CONCURRENCY_LEVEL = 16;

• DEFAULT_CONCURRENCY_LEVEL：表示默認的並發級別，也就是table[]的默認大小。

1. private static final float LOAD_FACTOR = 0.75f;

• LOAD_FACTOR：默認的負載因子。

1. static final int TREEIFY_THRESHOLD = 8;

• TREEIFY_THRESHOLD：鏈表轉紅黑樹的閥值，當table[i]下面的鏈表長度大於8時就轉化為紅黑樹結構。

1. static final int UNTREEIFY_THRESHOLD = 6;

• UNTREEIFY_THRESHOLD：紅黑樹轉鏈表的閥值，當鏈表長度<=6時轉為鏈表（擴容時）。

構造函數

1. public ConcurrentHashMap(int initialCapacity,
2. float loadFactor, int concurrencyLevel) {
3. if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
4. throw new IllegalArgumentException();
5. if (initialCapacity < concurrencyLevel) // 初始化容量至少要為concurrencyLevel
6. initialCapacity = concurrencyLevel;
7. long size = (long)(1.0 + (long)initialCapacity / loadFactor);
8. int cap = (size >= (long)MAXIMUM_CAPACITY) ?
9. MAXIMUM_CAPACITY : tableSizeFor((int)size);
10. this.sizeCtl = cap;
11. }

從上面代碼可以看出，在創建ConcurrentHashMap時，並沒有初始化table[]數組，只對Map容量，並發級別等做了賦值操作。
相關節點

1. Node：該類用於構造table[]，只讀節點（不提供修改方法）。
2. TreeBin：紅黑樹結構。
3. TreeNode：紅黑樹節點。
4. ForwardingNode：臨時節點（擴容時使用）。

put()操作

1. public V put(K key, V value) {
2. return putVal(key, value, false);
3. }
5. final V putVal(K key, V value, boolean onlyIfAbsent) {
6. if (key == null || value == null) throw new NullPointerException();
7. int hash = spread(key.hashCode());
8. int binCount = 0;
9. for (Node<K,V>[] tab = table;;) {
10. Node<K,V> f; int n, i, fh;
11. if (tab == null || (n = tab.length) == 0)// 若table[]未創建，則初始化
12. tab = initTable();
13. else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {// table[i]後面無節點時，直接創建Node（無鎖操作）
14. if (casTabAt(tab, i, null,
15. new Node<K,V>(hash, key, value, null)))
16. break; // no lock when adding to empty bin
17. }
18. else if ((fh = f.hash) == MOVED)// 如果當前正在擴容，則幫助擴容並返回最新table[]
19. tab = helpTransfer(tab, f);
20. else {// 在鏈表或者紅黑樹中追加節點
21. V oldVal = null;
22. synchronized (f) {// 這裏並沒有使用ReentrantLock，說明synchronized已經足夠優化了
23. if (tabAt(tab, i) == f) {
24. if (fh >= 0) {// 如果為鏈表結構
25. binCount = 1;
26. for (Node<K,V> e = f;; ++binCount) {
27. K ek;
28. if (e.hash == hash &&
29. ((ek = e.key) == key ||
30. (ek != null && key.equals(ek)))) {// 找到key，替換value
31. oldVal = e.val;
32. if (!onlyIfAbsent)
33. e.val = value;
34. break;
35. }
36. Node<K,V> pred = e;
37. if ((e = e.next) == null) {// 在尾部插入Node
38. pred.next = new Node<K,V>(hash, key,
39. value, null);
40. break;
41. }
42. }
43. }
44. else if (f instanceof TreeBin) {// 如果為紅黑樹
45. Node<K,V> p;
46. binCount = 2;
47. if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
48. value)) != null) {
49. oldVal = p.val;
50. if (!onlyIfAbsent)
51. p.val = value;
52. }
53. }
54. }
55. }
56. if (binCount != 0) {
57. if (binCount >= TREEIFY_THRESHOLD)// 到達閥值，變為紅黑樹結構
58. treeifyBin(tab, i);
59. if (oldVal != null)
60. return oldVal;
61. break;
62. }
63. }
64. }
65. addCount(1L, binCount);
66. return null;
67. }

從上面代碼可以看出，put的步驟大致如下：

1. 參數校驗。
2. 若table[]未創建，則初始化。
3. 當table[i]後面無節點時，直接創建Node（無鎖操作）。
4. 如果當前正在擴容，則幫助擴容並返回最新table[]。
5. 然後在鏈表或者紅黑樹中追加節點。
6. 最後還回去判斷是否到達閥值，如到達變為紅黑樹結構。

除了上述步驟以外，還有一點我們留意到的是，代碼中加鎖片段用的是synchronized關鍵字，而不是像1.7中的ReentrantLock。這一點也說明了，synchronized在新版本的JDK中優化的程度和ReentrantLock差不多了。
get()操作

1. public V get(Object key) {
2. Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
3. int h = spread(key.hashCode());// 定位到table[]中的i
4. if ((tab = table) != null && (n = tab.length) > 0 &&
5. (e = tabAt(tab, (n - 1) & h)) != null) {// 若table[i]存在
6. if ((eh = e.hash) == h) {// 比較鏈表頭部
7. if ((ek = e.key) == key || (ek != null && key.equals(ek)))
8. return e.val;
9. }
10. else if (eh < 0)// 若為紅黑樹，查找樹
11. return (p = e.find(h, key)) != null ? p.val : null;
12. while ((e = e.next) != null) {// 循環鏈表查找
13. if (e.hash == h &&
14. ((ek = e.key) == key || (ek != null && key.equals(ek))))
15. return e.val;
16. }
17. }
18. return null;// 未找到
19. }

get()方法的流程相對簡單一點，從上面代碼可以看出以下步驟：

1. 首先定位到table[]中的i。
2. 若table[i]存在，則繼續查找。
3. 首先比較鏈表頭部，如果是則返回。
4. 然後如果為紅黑樹，查找樹。
5. 最後再循環鏈表查找。

從上面步驟可以看出，ConcurrentHashMap的get操作上面並沒有加鎖。所以在多線程操作的過程中，並不能完全的保證一致性。這裏和1.7當中類似，是弱一致性的體現。
size()操作

1. // 1.2時加入
2. public int size() {
3. long n = sumCount();
4. return ((n < 0L) ? 0 :
5. (n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
6. (int)n);
7. }
8. // 1.8加入的API
9. public long mappingCount() {
10. long n = sumCount();
11. return (n < 0L) ? 0L : n; // ignore transient negative values
12. }
14. final long sumCount() {
15. CounterCell[] as = counterCells; CounterCell a;
16. long sum = baseCount;
17. if (as != null) {
18. for (int i = 0; i < as.length; ++i) {
19. if ((a = as[i]) != null)
20. sum += a.value;
21. }
22. }
23. return sum;
24. }

從上面代碼可以看出來，JDK1.8中新增了一個mappingCount()的API。這個API與size()不同的就是返回值是Long類型，這樣就不受Integer.MAX_VALUE的大小限制了。
兩個方法都同時調用了，sumCount()方法。對於每個table[i]都有一個CounterCell與之對應，上面方法做了求和之後就返回了。從而可以看出，size()和mappingCount()返回的都是一個估計值。（這一點與JDK1.7裏面的實現不同，1.7裏面使用了加鎖的方式實現。這裏面也可以看出JDK1.8犧牲了精度，來換取更高的效率。）

ConcurrentHashMap的JDK1.8實現