Java：ConcurrentHashMap是弱一致的

本文將用到Java內存模型的happens-before偏序關系（下文將簡稱為hb）以及ConcurrentHashMap的底層模型相關的知識。happens-before相關內容參見：JLS §17.4.5. Happens-before Order、深入理解Java內存模型以及Happens before；ConcurrentHashMap的詳細介紹以及底層原理見深入分析ConcurrentHashMap。本文將從ConcurrentHashMap的get，clear，iterator（entrySet、keySet、values方法）三個方法來分析它們的弱一致問題。

 

ConcurrentHashMap#get

get方法是弱一致的，是什么含義？可能你期望往ConcurrentHashMap底層數據結構中加入一個元素后，立馬能對get可見，但ConcurrentHashMap並不能如你所願。換句話說，put操作將一個元素加入到底層數據結構后，get可能在某段時間內還看不到這個元素，若不考慮內存模型，單從代碼邏輯上來看，卻是應該可以看得到的。

下面將結合代碼和java內存模型相關內容來分析下put/get方法（本文中所有ConcurrentHashMap相關的代碼均來自hotspot1.6.0_18）。put方法我們只需關注Segment#put，get方法只需關注Segment#get，在繼續之前，先要說明一下Segment里有兩個volatile變量：count和table；HashEntry里有一個volatile變量：value。

Segment#put

01	V put(K key, int hash, V value, boolean onlyIfAbsent) {

02

lock();

03

try {

04	int c = count;

05	if (c++ > threshold) // ensure capacity

06

rehash();

07	HashEntry<K,V>[] tab = table;

08	int index = hash & (tab.length - 1);

09	HashEntry<K,V> first = tab[index];

10	HashEntry<K,V> e = first;

11	while (e != null && (e.hash != hash || !key.equals(e.key)))

12	e = e.next;

13

14	V oldValue;

15	if (e != null) {

16	oldValue = e.value;

17	if (!onlyIfAbsent)

18	e.value = value;

19

}

20

else {

21	oldValue = null;

22	++modCount;

23	tab[index] = new HashEntry<K,V>(key, hash, first, value);

24	count = c; // write-volatile

25

}

26	return oldValue;

27	} finally {

28

unlock();

29

}

30

}

Segment#get

01	V get(Object key, int hash) {

02	if (count != 0) { // read-volatile

03	HashEntry<K,V> e = getFirst(hash);

04	while (e != null) {

05	if (e.hash == hash && key.equals(e.key)) {

06	V v = e.value;

07	if (v != null)

08

return v;

09	return readValueUnderLock(e); // recheck

10

}

11	e = e.next;

12

}

13

}

14	return null;

15

}

我們如何確定線程1放入某個變量的值是否對線程2可見？文章開頭提到的JLS鏈接中有說到，當a hb c時，a對c可見，那么我們接下來我們只要尋找put和get之間所有可能的執行軌跡上的hb關系。要找出hb關系，我們需要先找出與hb相關的Action。為方便，這里將兩段代碼放到了一張圖片上。

可以注意到，同一個Segment實例中的put操作是加了鎖的，而對應的get卻沒有。根據hb關系中的線程間Action類別，可以從上圖中找出這些Action，主要是volatile讀寫和加解鎖，也就是圖中畫了橫線的那些。

put操作可以分為兩種情況，一是key已經存在，修改對應的value；二是key不存在，將一個新的Entry加入底層數據結構。

key已經存在的情況比較簡單，即if (e != null)部分，前面已經說過HashEntry的value是個volatile變量，當線程1給value賦值后，會立馬對執行get的線程2可見，而不用等到put方法結束。

key不存在的情況稍微復雜一些，新加一個Entry的邏輯在else中。那么將new HashEntry賦值給tab[index]是否能立刻對執行get的線程可見呢？我們只需分析寫tab[index]與讀取tab[index]之間是否有hb關系即可。

假設執行put的線程與執行get的線程的軌跡是這樣的

執行put的線程	執行get的線程
⑧tab[index] = new HashEntry<K,V>(key, hash, first, value)
②count = c
	③if (count != 0)
	⑨HashEntry e = getFirst(hash);

tab變量是一個普通的變量，雖然給它賦值的是volatile的table。另外，雖然引用類型（數組類型）的變量table是volatile的，但table中的元素不是volatile的，因此⑧只是一個普通的寫操作；count變量是volatile的，因此②是一個volatile寫；③很顯然是一個volatile讀；⑨中getFirst方法中讀取了table，因此包含一個volatile讀。

根據Synchronization Order，對同一個volatile變量，有volatile寫 hb volatile讀。在這個執行軌跡中，時間上②在③之前發生，且②是寫count，③是讀count，都是針對同一個volatile變量count，因此有② hb ③；又因為⑧和②是同一個線程中的，③和⑨是同一個線程中的，根據Program Order，有⑧ hb ②，③ hb ⑨。目前我們有了三組關系了⑧ hb ②，② hb ③，③ hb ⑨，再根據hb關系是可傳遞的（即若有x hb y且y hb z，可得出x hb z），可以得出⑧ hb ⑨。因此，如果按照上述執行軌跡，⑧中寫入的數組元素對⑨中的讀取操作是可見的。

再考慮這樣一個執行軌跡：

執行put的線程	執行get的線程
⑧tab[index] = new HashEntry<K,V>(key, hash, first, value)
	③if (count != 0)
②count = c
	⑨HashEntry e = getFirst(hash);

這里只是變換了下執行順序。每條語句的volatile讀寫含義同上，但它們之間的hb關系卻改變了。Program Order是我們一直擁有的，即我們有⑧ hb ②，③ hb ⑨。但這次對volatile的count的讀時間上發生在對count的寫之前，我們無法得出② hb ⑨這層關系了。因此，通過count變量，在這個軌跡上是無法得出⑧ hb ⑨的。那么，存不存在其它可替換關系，讓我們仍能得出⑧ hb ⑨呢？

我們要找的是，在⑧之后有一條語句或指令x，在⑨之前有一條語句或指令y，存在x hb y。這樣我們可以有⑧ hb x，x hb y， y hb ⑨。就讓我們來找一下是否存在這樣的x和y。圖中的⑤、⑥、⑦、①存在volatile讀寫，但是它們在⑧之前，因此對確立⑧ hb ⑨這個關系沒有用處；同理，④在⑨之后，我們要找的是⑨之前的，因此也對這個問題無益。前面已經分析過了②，③之間沒法確立hb關系。

在⑧之后，我們發現一個unlock操作，如果能在⑨之前找到一個lock操作，那么我們要找的x就是unlock，要找的y就是lock，因為Synchronization Order中有unlock hb lock的關系。但是，很不幸運，⑨之前沒有lock操作。因此，對於這樣的軌跡，是沒有⑧ hb ⑨關系的，也就是說，如果某個Segment實例中的put將一個Entry加入到了table中，在未執行count賦值操作之前有另一個線程執行了同一個Segment實例中的get，來獲取這個剛加入的Entry中的value，那么是有可能取不到的！

此外，如果getFirst(hash)先執行，tab[index] = new HashEntry<K,V>(key, hash, first, value)后執行，那么，這個get操作也是看不到put的結果的。

……

正是因為get操作幾乎所有時候都是一個無鎖操作（get中有一個readValueUnderLock調用，不過這句執行到的幾率極小），使得同一個Segment實例上的put和get可以同時進行，這就是get操作是弱一致的根本原因。Java API中對此有一句簡單的描述:

Retrievals reflect the results of the most recently completed update operations holding upon their onset.

也就是說API上保證get操作一定能看到已完成的put操作。已完成的put操作肯定在get讀取count之前對count做了寫入操作。因此，也就是我們第一個軌跡分析的情況。

ConcurrentHashMap#clear

clear方法很簡單，看下代碼即知。

1	public void clear() {

2	for (int i = 0; i < segments.length; ++i)

3	segments[i].clear();

4

}

因為沒有全局的鎖，在清除完一個segments之后，正在清理下一個segments的時候，已經清理segments可能又被加入了數據，因此clear返回的時候，ConcurrentHashMap中是可能存在數據的。因此，clear方法是弱一致的。

ConcurrentHashMap中的迭代器

ConcurrentHashMap中的迭代器主要包括entrySet、keySet、values方法。它們大同小異，這里選擇entrySet解釋。當我們調用entrySet返回值的iterator方法時，返回的是EntryIterator，在EntryIterator上調用next方法時，最終實際調用到了HashIterator.advance()方法，看下這個方法：

01	final void advance() {

02	if (nextEntry != null && (nextEntry = nextEntry.next) != null)

03

return;

04

05	while (nextTableIndex >= 0) {

06	if ( (nextEntry = currentTable[nextTableIndex--]) != null)

07

return;

08

}

09

10	while (nextSegmentIndex >= 0) {

11	Segment<K,V> seg = segments[nextSegmentIndex--];

12	if (seg.count != 0) {

13	currentTable = seg.table;

14	for (int j = currentTable.length - 1; j >= 0; --j) {

15	if ( (nextEntry = currentTable[j]) != null) {

16	nextTableIndex = j - 1;

17

return;

18

}

19

}

20

}

21

}

22

}

這個方法在遍歷底層數組。在遍歷過程中，如果已經遍歷的數組上的內容變化了，迭代器不會拋出ConcurrentModificationException異常。如果未遍歷的數組上的內容發生了變化，則有可能反映到迭代過程中。這就是ConcurrentHashMap迭代器弱一致的表現。

總結

ConcurrentHashMap的弱一致性主要是為了提升效率，是一致性與效率之間的一種權衡。要成為強一致性，就得到處使用鎖，甚至是全局鎖，這就與Hashtable和同步的HashMap一樣了。

原創文章，轉載請注明： 轉載自並發編程網 – ifeve.com本文鏈接地址: 為什么ConcurrentHashMap是弱一致的