oncurrentModificationException

在這種迭代方式中，當iterator被建立後集合再發生改變就不再是丟擲ConcurrentModificationException， 取而代之的是在改變時new新的資料從而不影響原有的資料 ，iterator完成後再將頭指標替換為新的資料 ，這樣iterator執行緒可以使用原來老的資料，而寫執行緒也可以併發的完成改變。

ConcurrentHashMap 原理：

集合是程式設計中最常用的資料結構。而談到併發，幾乎總是離不開集合這類高階資料結構的支援。比如兩個執行緒需要同時訪問一箇中間臨界區 （Queue），比如常會用快取作為外部檔案的副本（HashMap）。這篇文章主要分析jdk1.5的3種併發集合型別 （concurrent，copyonright，queue）中的ConcurrentHashMap，讓我們從原理上細緻的瞭解它們，能夠讓我們在深 度專案開發中獲益非淺。

    在tiger之前，我們使用得最多的資料結構之一就是HashMap和Hashtable。大家都知道，HashMap中未進行同步考慮，而Hashtable則使用了synchronized，帶來的直接影響就是可選擇，我們可以在單執行緒時使用HashMap提高效率，而多執行緒時用Hashtable來保證安全。     當我們享受著jdk帶來的便利時同樣承受它帶來的不幸惡果。通過分析Hashtable就知道，synchronized是針對整張Hash表的，即每次鎖住整張表讓執行緒獨佔，安全的背後是巨大的浪費，慧眼獨具的Doug Lee立馬拿出瞭解決方案----ConcurrentHashMap。     ConcurrentHashMap和Hashtable主要區別就是圍繞著鎖的粒度以及如何鎖。如圖

    左邊便是Hashtable的實現方式---鎖整個hash表；而右邊則是ConcurrentHashMap的實現方式---鎖桶（或段）。 ConcurrentHashMap將hash表分為16個桶（預設值），諸如get,put,remove等常用操作只鎖當前需要用到的桶。試想，原來 只能一個執行緒進入，現在卻能同時16個寫執行緒進入（寫執行緒才需要鎖定，而讀執行緒幾乎不受限制，之後會提到），併發性的提升是顯而易見的。     更令人驚訝的是ConcurrentHashMap的讀取併發，因為在讀取的大多數時候都沒有用到鎖定，所以讀取操作幾乎是完全的併發操作，而寫操作鎖定的粒度又非常細，比起之前又更加快速（這一點在桶更多時表現得更明顯些）。只有在求size等操作時才需要鎖定整個表。而在迭代時，ConcurrentHashMap使用了不同於傳統集合的快速失敗迭代器（見之前的文章《JAVA API備忘---集合》）的另一種迭代方式，我們稱為弱一致迭代器。在這種迭代方式中，當iterator被建立後集合再發生改變就不再是丟擲ConcurrentModificationException，取而代之的是在改變時new新的資料從而不影響原有的資料，iterator完成後再將頭指標替換為新的資料，這樣iterator執行緒可以使用原來老的資料，而寫執行緒也可以併發的完成改變，更重要的，這保證了多個執行緒併發執行的連續性和擴充套件性，是效能提升的關鍵。     接下來，讓我們看看ConcurrentHashMap中的幾個重要方法，心裡知道了實現機制後，使用起來就更加有底氣。     ConcurrentHashMap中主要實體類就是三個：ConcurrentHashMap（整個Hash表）,Segment（桶），HashEntry（節點），對應上面的圖可以看出之間的關係。     get方法（請注意，這裡分析的方法都是針對桶的，因為ConcurrentHashMap的最大改進就是將粒度細化到了桶上），首先判斷了當前桶的資料 個數是否為0，為0自然不可能get到什麼，只有返回null，這樣做避免了不必要的搜尋，也用最小的代價避免出錯。然後得到頭節點（方法將在下面涉及） 之後就是根據hash和key逐個判斷是否是指定的值，如果是並且值非空就說明找到了，直接返回；程式非常簡單，但有一個令人困惑的地方，這句 return readValueUnderLock(e)到底是用來幹什麼的呢？研究它的程式碼，在鎖定之後返回一個值。但這裡已經有一句V v = e.value得到了節點的值，這句return readValueUnderLock(e)是否多此一舉？事實上，這裡完全是為了併發考慮的，這裡當v為空時，可能是一個執行緒正在改變節點，而之前的get操作都未進行鎖定，根據bernstein條件，讀後寫或寫後讀都會引起資料的不一致，所以這裡要對這個e重新上鎖再讀一遍，以保證得到的是正確值，這裡不得不佩服Doug Lee思維的嚴密性。整個get操作只有很少的情況會鎖定，相對於之前的Hashtable，併發是不可避免的啊！ Java程式碼  

1. V get(Object key, int hash) {  
2.     if (count != 0) { // read-volatile  
3.         HashEntry e = getFirst(hash);  
4.         while (e != null) {  
5.             if (e.hash == hash && key.equals(e.key)) {  
6.                 V v = e.value;  
7.                 if (v != null)  
8.                     return v;  
9.                 return readValueUnderLock(e); // recheck  
10.             }  
11.             e = e.next;  
12.         }  
13.     }  
14.     return null;  
15. }  
16. V readValueUnderLock(HashEntry e) {  
17.     lock();  
18.     try {  
19.         return e.value;  
20.     } finally {  
21.         unlock();  
22.     }  
23. }  

put操作一上來就鎖定了整個segment，這當然是為了併發的安全，修改資料是不能併發進行的，必須得有個判斷是否超限的語句以確保容量不足時能夠rehash，而比較難懂的是這句int index = hash & (tab.length - 1)，原來segment裡面才是真正的hashtable，即每個segment是一個傳統意義上的hashtable,如上圖，從兩者的結構就可以看出區別，這裡就是找出需要的entry在table的哪一個位置，之後得到的entry就是這個鏈的第一個節點，如果e!=null，說明找到了，這是就要替換節點的值（onlyIfAbsent == false），否則，我們需要new一個entry，它的後繼是first，而讓tab[index]指向它，什麼意思呢？實際上就是將這個新entry插入到鏈頭，剩下的就非常容易理解了。

Java程式碼  

1. V put(K key, int hash, V value, boolean onlyIfAbsent) {  
2.     lock();  
3.     try {  
4.         int c = count;  
5.         if (c++ > threshold) // ensure capacity  
6.             rehash();  
7.         HashEntry[] tab = table;  
8.         int index = hash & (tab.length - 1);  
9.         HashEntry first = (HashEntry) tab[index];  
10.         HashEntry e = first;  
11.         while (e != null && (e.hash != hash || !key.equals(e.key)))  
12.             e = e.next;  
13.         V oldValue;  
14.         if (e != null) {  
15.             oldValue = e.value;  
16.             if (!onlyIfAbsent)  
17.                 e.value = value;  
18.         }  
19.         else {  
20.             oldValue = null;  
21.             ++modCount;  
22.             tab[index] = new HashEntry(key, hash, first, value);  
23.             count = c; // write-volatile  
24.         }  
25.         return oldValue;  
26.     } finally {  
27.         unlock();  
28.     }  
29. }  

   remove操作非常類似put，但要注意一點區別，中間那個for迴圈是做什麼用的呢？（*號標記）從程式碼來看，就是將定位之後的所有entry克隆並拼回前面去，但有必要嗎？每次刪除一個元素就要將那之前的元素克隆一遍？這點其實是由entry 的不變性來決定的，仔細觀察entry定義，發現除了value，其他所有屬性都是用final來修飾的，這意味著在第一次設定了next域之後便不能再 改變它，取而代之的是將它之前的節點全都克隆一次。至於entry為什麼要設定為不變性，這跟不變性的訪問不需要同步從而節省時間有關，關於不變性的更多 內容，請參閱之前的文章《執行緒高階---執行緒的一些程式設計技巧》

Java程式碼  

1. V remove(Object key, int hash, Object value) {  
2.     lock();  
3.     try {  
4.         int c = count - 1;  
5.         HashEntry[] tab = table;  
6.         int index = hash & (tab.length - 1);  
7.         HashEntry first = (HashEntry)tab[index];  
8.         HashEntry e = first;  
9.         while (e != null && (e.hash != hash || !key.equals(e.key)))  
10.             e = e.next;  
11.         V oldValue = null;  
12.         if (e != null) {  
13.             V v = e.value;  
14.             if (value == null || value.equals(v)) {  
15.                 oldValue = v;  
16.                 // All entries following removed node can stay  
17.                 // in list, but all preceding ones need to be  
18.                 // cloned.  
19.                 ++modCount;  
20.                 HashEntry newFirst = e.next;  
21.             *    for (HashEntry p = first; p != e; p = p.next)  
22.             *        newFirst = new HashEntry(p.key, p.hash,   
23.                                                   newFirst, p.value);  
24.                 tab[index] = newFirst;  
25.                 count = c; // write-volatile  
26.             }  
27.         }  
28.         return oldValue;  
29.     } finally {  
30.         unlock();  
31.     }  
32. }  

Java程式碼  

1. static final class HashEntry {  
2.     final K key;  
3.     final int hash;  
4.     volatile V value;  
5.     final HashEntry next;  
6.     HashEntry(K key, int hash, HashEntry next, V value) {  
7.         this.key = key;  
8.         this.hash = hash;  
9.         this.next = next;  
10.         this.value = value;  
11.     }  
12. }  

util.concurrent 包中的 ConcurrentHashMap 類（也將出現在JDK 1.5中的 java.util.concurrent 包中）是對 Map 的執行緒安全的實現，比起 synchronizedMap 來，它提供了好得多的併發性。多個讀操作幾乎總可以併發地執行，同時進行的讀和寫操作通常也能併發地執行，而同時進行的寫操作仍然可以不時地併發進行（相關的類也提供了類似的多個讀執行緒的併發性，但是，只允許有一個活動的寫執行緒） 。ConcurrentHashMap 被設計用來優化檢索操作；實際上，成功的 get() 操作完成之後通常根本不會有鎖著的資源。要在不使用鎖的情況下取得執行緒安全性需要一定的技巧性，並且需要對Java記憶體模型（Java Memory Model）的細節有深入的理解。ConcurrentHashMap 實現，加上 util.concurrent 包的其他部分，已經被研究正確性和執行緒安全性的併發專家所正視。在下個月的文章中，我們將看看 ConcurrentHashMap 的實現的細節。

ConcurrentHashMap 通過稍微地鬆弛它對呼叫者的承諾而獲得了更高的併發性。檢索操作將可以返回由最近完成的插入操作所插入的值，也可以返回在步調上是併發的插入操作所新增的值（但是決不會返回一個沒有意義的結果）。由 ConcurrentHashMap.iterator() 返回的 Iterators 將每次最多返回一個元素，並且決不會丟擲ConcurrentModificationException 異常，但是可能會也可能不會反映在該迭代器被構建之後發生的插入操作或者移除操作。在對 集合進行迭代時，不需要表範圍的鎖就能提供執行緒安全性。在任何不依賴於鎖整個表來防止更新的應用程式中，可以使用 ConcurrentHashMap 來替代 synchronizedMap 或 Hashtable 。

上述改進使得 ConcurrentHashMap 能夠提供比 Hashtable 高得多的可伸縮性，而且，對於很多型別的公用案例（比如共享的cache）來說，還不用損失其效率。

好了多少？

表 1對 Hashtable 和  ConcurrentHashMap 的可伸縮性進行了粗略的比較。在每次執行過程中， n 個執行緒併發地執行一個死迴圈，在這個死迴圈中這些執行緒從一個 Hashtable 或者 ConcurrentHashMap 中檢索隨機的key value，發現在執行 put() 操作時有80%的檢索失敗率，在執行操作時有1%的檢索成功率。測試所在的平臺是一個雙處理器的Xeon系統，作業系統是Linux。資料顯示了10,000,000次迭代以毫秒計的執行時間，這個資料是在將對 ConcurrentHashMap的 操作標準化為一個執行緒的情況下進行統計的。您可以看到，當執行緒增加到多個時，ConcurrentHashMap 的效能仍然保持上升趨勢，而 Hashtable 的效能則隨著爭用鎖的情況的出現而立即降了下來。

比起通常情況下的伺服器應用，這次測試中執行緒的數量看上去有點少。然而，因為每個執行緒都在不停地對錶進行操作，所以這與實際環境下使用這個表的更多數量的執行緒的爭用情況基本等同。

執行緒數	ConcurrentHashMap	Hashtable
1	1.00	1.03
2	2.59	32.40
4	5.58	78.23
8	13.21	163.48
16	27.58	341.21
32	57.27	778.41