CocurrentHashMap的優勢

首先常用三種HashMap包括HashMap,HashTable和CocurrentHashMap：

• HashMap在併發程式設計過程中使用可能導致死迴圈，因為插入過程不是原子操作，每個HashEntry是一個連結串列節點，很可能在插入的過程中，已經設定了後節點，實際還未插入，最終反而插入在後節點之後，造成鏈中出現環，破壞了連結串列的性質，失去了尾節點，出現死迴圈。
• HashTable因為內部是採用synchronized來保證執行緒安全的，但線上程競爭激烈的情況下HashTable的效率下降得很快因為synchronized關鍵字會造成程式碼塊或方法成為為臨界區(對同一個物件加互斥鎖)，當一個執行緒訪問臨界區的程式碼時，其他執行緒也訪問同一臨界區時，會進入阻塞或輪詢狀態。究其原因，實際上是有獲取鎖意向的執行緒的數目增加，但是鎖還是隻有單個，導致大量的執行緒處於輪詢或阻塞，導致同一時間段有效執行的執行緒的增量遠不及執行緒總體增量。
  
  • 在查詢時，尤其能夠體現出CocurrentHashMap在效率上的優勢，HashTable使用Sychronized關鍵字，會導致同時只能有一個查詢在執行，而Cocurrent則不採取加鎖的方法，而是採用volatile關鍵字，雖然也會犧牲效率，但是由於Sychronized，於該文末尾繼續討論。
• CocurrentHashMap利用鎖分段技術增加了鎖的數目，從而使爭奪同一把鎖的執行緒的數目得到控制。
  
  • 鎖分段技術就是對資料集進行分段，每段競爭一把鎖，不同資料段的資料不存在鎖競爭，從而有效提高 高併發訪問效率。
  • CocurrentHashMap在get方法是無需加鎖的，因為用到的共享變數都採用volatile關鍵字修飾，巴證共享變數線上程之間的可見性(每次讀取都先同步快取和記憶體，直接從記憶體中獲取值，雖然不是原子操作，但根據JAVA記憶體模型的happen before原則，對volatile欄位的寫入操作先於讀操作，能夠保證不會髒讀),volatile為了讓變數提供執行緒之間的記憶體可見性，會禁止程式執行結果的重排序（導致快取優化的效果降低）

CocurrentHashMap的結構

• CocurrentHashMap是由Segment陣列和HashEntry陣列組成。
• Segment是重入鎖(ReentrantLock),作為一個數據段競爭鎖，每個HashEntry一個連結串列結構的元素，利用Hash演算法得到索引確定歸屬的資料段，也就是對應到在修改時需要競爭獲取的鎖。

segments陣列的初始化

• 首先簡單描述一下原始碼中變數的含義:

• 首先計算出segment陣列的長度ssize，並且計算出與ssize關聯的segmentShift和segmentMask

if ( cocurrencyLevel > MAX_SEGMENTS )
    cocurrencyLevel = MAX_SEGMENTS;
//如果cocurrencyLevel大於上限，那麼取值為上限，
//上限定義為65535，決定了重入鎖的segments的數目
int sshift = 0;
int ssize = 1;
//找到大於等於concurrencyLevel的最小的2^n作為segments的大小
while ( ssize < concurrencyLevel ){
    ++sshift;//記錄偏移量，為了以後通過與運算獲取segment的索引
    ssize <<=1;
}
segmentShift = 32 - sshift;//說明只有高sshift位作為segment的索引
segmentMask = ssize - 1;//能直接通過與運算獲取segment的索引
this.segments = Segment.newArray(ssize);
//靜態工廠方法構造ssize大小的segment陣列

• 初始化每個segment,因為已經知道segment陣列的規模，將ConcurrentHashMap的邏輯上持有的HashEntry均分到每個Segment上，因為是雜湊，所以要loadFactor來定義負載率，來保證segment適時的拓充，來避免散列表和資料規模相近時，衝突加重的風險。

if ( initialCapacity > MAXIMUM_CAPACITY )
    initialCapacity = MAXIMUM_CAPACITY;
int c = initCapacity / ssize;
//整個cocurrentHashMap的容量由所有的segment均攤
if ( c * ssize < initCapacity )
    ++c;
int cap = 1;//segment中的hashEntry陣列的長度
while ( cap < c )
    cap <<= 1;
//設定loadFactor,保證雜湊的高效性的同時也保證空間浪費相對有限
for ( int i = 0 ; i < this.segments.length ; i++ )
    this.segments[i] =  new Segments<K,V>(cap , loadFactor);
//最終計算出segment的容量threshold=(int)cap*loadFactor;

• 定位segment，定位segment尤其重要，如果太多元素集中在少數幾個segment中會導致CocurrentHashMap的效率得不到優化，因為同一個segment中的修改還是要競爭鎖，所以選擇合適的hash演算法儘可能地將元素分到不同的segment中是目標。
  
  • CocurrentHashMap採用的是對元素的HashCode進行再Hash來減少衝突
  • CocurrentHashMap採用的是根據Wang/JenkinsHash改進的hash演算法，該演算法具有雪崩性(引數一位數字變化，結果都有半數左右(二進位制位)發生變化)

final Segment<K,V> segmentFor ( int hash ){
    //首先根據segmentShift無符號右移，得到表示segment所以的高位，
    //然後與掩碼邏輯與得到segment的索引，定位到segment
    return segments[(hash>>>segmentShift)&segmentMask];
}

CocurrentHashMap的操作

• Segment的get操作是不需要加鎖的。因為volatile修飾的變數保證了執行緒之間的可見性
• Segment的put操作是需要加鎖的，在插入時會先判斷Segment裡的HashEntry陣列是否會超過容量(threshold),如果超過需要對陣列擴容，翻一倍。然後在新的陣列中重新hash，為了高效，CocurrentHashMap只會對需要擴容的單個Segment進行擴容
• CocurrentHashMap獲取size的時候要統計Segments中的HashEntry的和，如果不對他們都加鎖的話，無法避免資料的修改造成的錯誤，但是如果都加鎖的話，效率又很低。所以CoccurentHashMap在實現的時候，巧妙地利用了在累加過程中發生變化的機率很小的客觀條件，在獲取count時，不加鎖的計算兩次，如果兩次不相同，在採用加鎖的計算方法。採用了一個高效率的剪枝防止很大概率地減少了不必要額加鎖。

一點理解

synchronized(其實感覺是可以被重入鎖和Condition完全取代的)和volatile的取捨：

• 首先的區別就在於是否是原子操作，也就是單一的不可分割的操作，在多執行緒中，原子操作能夠保證不受到其他執行緒的影響
• synchonized就實現了原子性操作，不同的執行緒互斥地進入臨界程式碼區，而且是記憶體可見的，也就是每個執行緒進入臨界區時，都是從記憶體中獲取的值，不會因為快取而出現髒讀。
• volatile實現了記憶體可見性，會將修改的值直接寫入內容，並且登出掉之前對於該變數的快取，而且禁止了指令的排序。但是它不是原子操作！！

參考書目

• Java多執行緒程式設計實戰指南
• Java併發程式設計的藝術
• Java多執行緒程式設計核心技術