Java並發編程之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。

左邊便是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並發編程之ConcurrentHashMap原理分析