站在巨人肩膀上看源碼-ConcurrentHashMap

時間  2019-12-06
標籤 站在 巨人 肩膀 上看 源碼 concurrenthashmap 欄目 Java 简体版
原文   原文鏈接

1、出現背景

一、線程不安全的HashMap

由於多線程環境下，使用Hashmap進行put操做會引發死循環，致使CPU利用率接近100%，因此在併發狀況下不能使用HashMap。node

二、效率低下的HashTable容器

HashTable容器使用synchronized來保證線程安全，但在線程競爭激烈的狀況下HashTable的效率很是低下。由於當一個線程訪問HashTable的同步方法時，其餘線程訪問HashTable的同步方法時，可能會進入阻塞或輪詢狀態。如線程1使用put進行添加元素，線程2不但不能使用put方法添加元素，而且也不能使用get方法來獲取元素，因此競爭越激烈效率越低。也就是說對於Hashtable而言，synchronized是針對整張Hash表的，即每次鎖住整張表讓線程獨佔。至關於全部線程進行讀寫時都去競爭一把鎖，致使效率很是低下。c++

三、ConcurrentHashMap的鎖分段技術

HashTable容器在競爭激烈的併發環境下表現出效率低下的緣由，是由於全部訪問HashTable的線程都必須競爭同一把鎖。那假如容器裏有多把鎖，每一把鎖用於鎖容器其中一部分數據，那麼當多線程訪問容器裏不一樣數據段的數據時，線程間就不會存在鎖競爭，從而能夠有效的提升併發訪問效率，這就是ConcurrentHashMap所使用的鎖分段技術，首先將數據分紅一段一段的存儲，而後給每一段數據配一把鎖，當一個線程佔用鎖訪問其中一個段數據的時候，其餘段的數據也能被其餘線程訪問。 另外，ConcurrentHashMap能夠作到讀取數據不加鎖，而且其內部的結構可讓其在進行寫操做的時候可以將鎖的粒度保持地儘可能地小，不用對整個ConcurrentHashMap加鎖。
ConcurrentHashMap是由Segment數組結構和HashEntry數組結構組成。Segment是一種可重入鎖ReentrantLock，在ConcurrentHashMap裏扮演鎖的角色，HashEntry則用於存儲鍵值對數據。一個ConcurrentHashMap裏包含一個Segment數組，Segment的結構和HashMap相似，是一種數組和鏈表結構， 一個Segment裏包含一個HashEntry數組，每一個HashEntry是一個鏈表結構的元素， 每一個Segment守護着一個HashEntry數組裏的元素，當對HashEntry數組的數據進行修改時，必須首先得到它對應的Segment鎖。數組

2、ConcurrentHashMap的內部結構

ConcurrentHashMap爲了提升自己的併發能力，在內部採用了一個叫作Segment的結構，一個Segment其實就是一個類Hash Table的結構，Segment內部維護了一個鏈表數組，咱們用下面這一幅圖來看下ConcurrentHashMap的內部結構：
249993-20170904153519210-1495243581.png安全

從上面的結構咱們能夠了解到，ConcurrentHashMap定位一個元素的過程須要進行兩次Hash操做，第一次Hash定位到Segment，第二次Hash定位到元素所在的鏈表的頭部，所以，這一種結構的帶來的反作用是Hash的過程要比普通的HashMap要長，可是帶來的好處是寫操做的時候能夠只對元素所在的Segment進行加鎖便可，不會影響到其餘的Segment，這樣，在最理想的狀況下，ConcurrentHashMap能夠最高同時支持Segment數量大小的寫操做（恰好這些寫操做都很是平均地分佈在全部的Segment上），因此，經過這一種結構，ConcurrentHashMap的併發能力能夠大大的提升。數據結構

一、Segment

咱們再來具體瞭解一下Segment的數據結構：多線程

static final class Segment<K,V> extends ReentrantLock implements Serializable { 
    transient volatile int count; 
    transient int modCount; 
    transient int threshold; 
    transient volatile HashEntry<K,V>[] table; 
    final float loadFactor; 
}

詳細解釋一下Segment裏面的成員變量的意義：併發

  • count：Segment中元素的數量
  • modCount：對table的大小形成影響的操做的數量（好比put或者remove操做）
  • threshold：閾值，Segment裏面元素的數量超過這個值就會對Segment進行擴容
  • table：鏈表數組，數組中的每個元素表明了一個鏈表的頭部
  • loadFactor：負載因子，用於肯定threshold

count用來統計該段數據的個數，它是volatile變量，它用來協調修改和讀取操做，以保證讀取操做可以讀取到幾乎最新的修改。協調方式是這樣的，每次修改操做作告終構上的改變，如增長/刪除節點(修改節點的值不算結構上的改變)，都要寫count值，每次讀取操做開始都要讀取count的值。這利用了 Java 5中對volatile語義的加強，對同一個volatile變量的寫和讀存在happens-before關係。modCount統計段結構改變的次數，主要是爲了檢測對多個段進行遍歷過程當中某個段是否發生改變，在講述跨段操做時會還會詳述。threashold用來表示須要進行rehash的界限值。table數組存儲段中節點，每一個數組元素是個hash鏈，用HashEntry表示。table也是volatile，這使得可以讀取到最新的 table值而不須要同步。loadFactor表示負載因子。app

二、HashEntry

Segment中的元素是以HashEntry的形式存放在鏈表數組中的，看一下HashEntry的結構：ssh

static final class HashEntry<K,V> { 
    final K key; 
    final int hash; 
    volatile V value; 
    final HashEntry<K,V> next; 
}

能夠看到HashEntry的一個特色，除了value之外，其餘的幾個變量都是final的，這意味着不能從hash鏈的中間或尾部添加或刪除節點，由於這須要修改next 引用值，全部的節點的修改只能從頭部開始。對於put操做，能夠一概添加到Hash鏈的頭部。可是對於remove操做，可能須要從中間刪除一個節點，這就須要將要刪除節點的前面全部節點整個複製一遍，最後一個節點指向要刪除結點的下一個結點。這在講解刪除操做時還會詳述。爲了確保讀操做可以看到最新的值，將value設置成volatile，這避免了加鎖。函數

3、ConcurrentHashMap的初始化

下面咱們來結合源代碼來具體分析一下ConcurrentHashMap的實現，先看下初始化方法

public ConcurrentHashMap(int initialCapacity, 
                         float loadFactor, int concurrencyLevel) { 
    if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0) 
        throw new IllegalArgumentException(); 
   
    if (concurrencyLevel > MAX_SEGMENTS) 
        concurrencyLevel = MAX_SEGMENTS; 
   
    // Find power-of-two sizes best matching arguments 
    int sshift = 0; 
    int ssize = 1; 
    while (ssize < concurrencyLevel) { 
        ++sshift; 
        ssize <<= 1; 
    } 
    segmentShift = 32 - sshift; 
    segmentMask = ssize - 1; 
    this.segments = Segment.newArray(ssize); 
   
    if (initialCapacity > MAXIMUM_CAPACITY) 
        initialCapacity = MAXIMUM_CAPACITY; 
    int c = initialCapacity / ssize; 
    if (c * ssize < initialCapacity) 
        ++c; 
    int cap = 1; 
    while (cap < c) 
        cap <<= 1; 
   
    for (int i = 0; i < this.segments.length; ++i) 
        this.segments[i] = new Segment<K,V>(cap, loadFactor); 
}

CurrentHashMap的初始化一共有三個參數，一個initialCapacity，表示初始的容量，一個loadFactor，表示負載參數，最後一個是concurrentLevel，表明ConcurrentHashMap內部的Segment的數量，ConcurrentLevel一經指定，不可改變，後續若是ConcurrentHashMap的元素數量增長致使ConrruentHashMap須要擴容，ConcurrentHashMap不會增長Segment的數量，而只會增長Segment中鏈表數組的容量大小，這樣的好處是擴容過程不須要對整個ConcurrentHashMap作rehash，而只須要對Segment裏面的元素作一次rehash就能夠了
整個ConcurrentHashMap的初始化方法仍是很是簡單的，先是根據concurrentLevel來new出Segment，這裏Segment的數量是不大於concurrentLevel的最大的2的指數，就是說Segment的數量永遠是2的指數個，這樣的好處是方便採用移位操做來進行hash，加快hash的過程。接下來就是根據intialCapacity肯定Segment的容量的大小，每個Segment的容量大小也是2的指數，一樣使爲了加快hash的過程。
這邊須要特別注意一下兩個變量，分別是segmentShift和segmentMask，這兩個變量在後面將會起到很大的做用，假設構造函數肯定了Segment的數量是2的n次方，那麼segmentShift就等於32減去n，而segmentMask就等於2的n次方減一。

4、ConcurrentHashMap的get操做

前面提到過ConcurrentHashMap的get操做是不用加鎖的，咱們這裏看一下其實現：

public V get(Object key) { 
     int hash = hash(key.hashCode()); 
     return segmentFor(hash).get(key, hash); 
 }

第二行，對hash值進行了二次hash，之因此要進行再哈希，其目的是爲了減小哈希衝突，使元素可以均勻的分佈在不一樣的Segment上，從而提升容器的存取效率。
看第三行，segmentFor這個函數用於肯定操做應該在哪個segment中進行，幾乎對ConcurrentHashMap的全部操做都須要用到這個函數，咱們看下這個函數的實現：

1 final Segment<K,V> segmentFor(int hash) { 
2     return segments[(hash >>> segmentShift) & segmentMask]; 
3 }

這個函數用了位操做來肯定Segment，根據傳入的hash值向右無符號右移segmentShift位，而後和segmentMask進行與操做，結合咱們以前說的segmentShift和segmentMask的值，就能夠得出如下結論：假設Segment的數量是2的n次方，根據元素的hash值的高n位就能夠肯定元素到底在哪個Segment中。
在肯定了須要在哪個segment中進行操做之後，接下來的事情就是調用對應的Segment的get方法：

V get(Object key, int hash) { 
    if (count != 0) { // read-volatile // ①
        HashEntry<K,V> e = getFirst(hash); 
        while (e != null) { 
            if (e.hash == hash && key.equals(e.key)) { 
                V v = e.value; 
                if (v != null) // ② 注意這裏
                    return v; 
                return readValueUnderLock(e); // recheck 
            } 
            e = e.next; 
        } 
    } 
    return null; 
}

先看第二行代碼，這裏對count進行了一次判斷，其中count表示Segment中元素的數量。咱們能夠來看一下count的定義：

transient volatile int count;

能夠看到count是volatile的，實際上這裏面利用了volatile的語義：
對volatile字段的寫入操做happens-before於每個後續的同一個字段的讀操做。由於實際上put、remove等操做也會更新count的值，因此當競爭發生的時候，volatile的語義能夠保證寫操做在讀操做以前，也就保證了寫操做對後續的讀操做都是可見的，這樣後面get的後續操做就能夠拿到完整的元素內容。
而後，在第三行，調用了getFirst()來取得鏈表的頭部：

1 HashEntry<K,V> getFirst(int hash) {
2     HashEntry<K,V>[] tab = table;
3     return tab[hash & (tab.length - 1)];
4 }

一樣，這裏也是用位操做來肯定鏈表的頭部，hash值和HashTable的長度減一作與操做，最後的結果就是hash值的低n位，其中n是HashTable的長度以2爲底的結果。
在肯定了鏈表的頭部之後，就能夠對整個鏈表進行遍歷，看第4行，取出key對應的value的值，若是拿出的value的值是null，則可能這個key，value對正在put的過程當中，若是出現這種狀況，那麼就加鎖來保證取出的value是完整的，若是不是null，則直接返回value。

get方法沒有使用鎖來同步，只是判斷獲取的entry的value是否爲null，爲null時才使用加鎖的方式再次去獲取。
這個實現很微妙，沒有鎖同步的話，靠什麼保證同步呢？咱們一步步分析。
第一步，先判斷一下 count != 0；count變量表示segment中存在entry的個數。若是爲0就不用找了。假設這個時候剛好另外一個線程put或者remove了這個segment中的一個entry，會不會致使兩個線程看到的count值不一致呢？看一下count 變量的定義：

transient volatile int count;

它使用了volatile來修改。在Java5以後，JMM實現了對volatile的保證：對volatile域的寫入操做happens-before於每個後續對同一個域的讀寫操做。因此，每次判斷count變量的時候，即便剛好其餘線程改變了segment也會體現出來。
第二步，獲取到要該key所在segment中的索引地址，若是該地址有相同的hash對象，順着鏈表一直比較下去找到該entry。當找到entry的時候，先作了一次比較： if(v != null) 咱們用紅色註釋的地方。這是爲什麼呢？考慮一下，若是這個時候，另外一個線程剛好新增/刪除了entry，或者改變了entry的value，會如何？
前面說過HashEntry類的結構，除了 value，其它成員都是final修飾的，也就是說value能夠被改變，其它都不能夠改變，包括指向下一個HashEntry的next也不能被改變。
（1）在get代碼的①和②之間，另外一個線程新增了一個entry。若是另外一個線程新增的這個entry又剛好是咱們要get的，這事兒就比較微妙了。下圖大體描述了put 一個新的entry的過程。
249993-20170911110607094-1237419873.jpg

由於每一個HashEntry中的next也是final的，無法對鏈表最後一個元素增長一個後續entry因此新增一個entry的實現方式只能經過頭結點來插入了。
newEntry對象是經過 new HashEntry(K k , V v, HashEntry next) 來建立的。若是另外一個線程恰好new 這個對象時，當前線程來get它。由於沒有同步，就可能會出現當前線程獲得的newEntry對象是一個沒有徹底構造好的對象引用。沒有鎖同步的話，new 一個對象對於多線程看到這個對象的狀態是沒有保障的，這裏一樣有可能一個線程new這個對象的時候尚未執行完構造函數就被另外一個線程獲得這個對象引用。因此才須要判斷一下：if (v != null) 若是確實是一個不完整的對象，則使用鎖的方式再次get一次。
有沒有可能會put進一個value爲null的entry？ 不會的，已經作了檢查，這種狀況會拋出異常，因此 ②處的判斷徹底是出於對多線程下訪問一個new出來的對象的狀態檢測。
（2）在get代碼的①和②之間，另外一個線程修改了一個entry的value。value是用volitale修飾的，能夠保證讀取時獲取到的是修改後的值。
（3）在get代碼的①以後，另外一個線程刪除了一個entry。
假設咱們的鏈表元素是：e1-> e2 -> e3 -> e4 咱們要刪除 e3這個entry，由於HashEntry中next的不可變，因此咱們沒法直接把e2的next指向e4，而是將要刪除的節點以前的節點複製一份，造成新的鏈表。它的實現大體以下圖所示：
249993-20170911135032750-1643188943.jpg

若是咱們get的也恰巧是e3，可能咱們順着鏈表剛找到e1，這時另外一個線程就執行了刪除e3的操做，而咱們線程還會繼續沿着舊的鏈表找到e3返回。這裏沒有辦法實時保證了。
咱們第①處就判斷了count變量，它保障了在 ①處能看到其餘線程修改後的。①以後到②之間，若是再次發生了其餘線程再刪除了entry節點，就無法保證看到最新的了。不過這也沒什麼關係，即便咱們返回e3的時候，它被其餘線程刪除了，暴漏出去的e3也不會對咱們新的鏈表形成影響。
這實際上是一種樂觀設計，設計者假設 ①以後到②之間 發生被其它線程增、刪、改的操做可能性很小，因此不採用同步設計，而是採用了過後（其它線程這期間也來操做，而且可能發生非安全事件）彌補的方式。而由於其餘線程的「改」和「刪」對咱們的數據都不會形成影響，因此只有對「新增」操做進行了安全檢查，就是②處的非null檢查，若是確認不安全事件發生，則採用加鎖的方式再次get。這樣作減小了使用互斥鎖對併發性能的影響。可能有人懷疑remove操做中複製鏈表的方式是否代價太大，這裏我沒有深刻比較，不過既然Java5中這麼實現，我想new一個對象的代價應該已經沒有早期認爲的那麼嚴重。

5、ConcurrentHashMap的put操做

看完了get操做，再看下put操做，put操做的前面也是肯定Segment的過程，這裏再也不贅述，直接看關鍵的segment的put方法：

V put(K key, int hash, V value, boolean onlyIfAbsent) { 
    lock(); 
    try { 
        int c = count; 
        if (c++ > threshold) // ensure capacity 
            rehash(); 
        HashEntry<K,V>[] tab = table; 
        int index = hash & (tab.length - 1); 
        HashEntry<K,V> first = tab[index]; 
        HashEntry<K,V> e = first; 
        while (e != null && (e.hash != hash || !key.equals(e.key))) 
            e = e.next; 
   
        V oldValue; 
        if (e != null) { 
            oldValue = e.value; 
            if (!onlyIfAbsent) 
                e.value = value; 
        } 
        else { 
            oldValue = null; 
            ++modCount; 
            tab[index] = new HashEntry<K,V>(key, hash, first, value); 
            count = c; // write-volatile 
        } 
        return oldValue; 
    } finally { 
        unlock(); 
    } 
}

首先對Segment的put操做是加鎖完成的，而後在第五行，若是Segment中元素的數量超過了閾值（由構造函數中的loadFactor算出）這須要進行對Segment擴容，而且要進行rehash，關於rehash的過程你們能夠本身去了解，這裏不詳細講了。
第8和第9行的操做就是getFirst的過程，肯定鏈表頭部的位置。
第11行這裏的這個while循環是在鏈表中尋找和要put的元素相同key的元素，若是找到，就直接更新更新key的value，若是沒有找到，則進入21行這裏，生成一個新的HashEntry而且把它加到整個Segment的頭部，而後再更新count的值。
該方法也是在持有段鎖(鎖定整個segment)的狀況下執行的，這固然是爲了併發的安全，修改數據是不能併發進行的，必須得有個判斷是否超限的語句以確保容量不足時可以rehash。接着是找是否存在一樣一個key的結點，若是存在就直接替換這個結點的值。不然建立一個新的結點並添加到hash鏈的頭部，這時必定要修改modCount和count的值，一樣修改count的值必定要放在最後一步。put方法調用了rehash方法，reash方法實現得也很精巧，主要利用了table的大小爲2^n，這裏就不介紹了。而比較難懂的是這句int index = hash & (tab.length - 1)，原來segment裏面纔是真正的hashtable，即每一個segment是一個傳統意義上的hashtable，如上圖，從二者的結構就能夠看出區別，這裏就是找出須要的entry在table的哪個位置，以後獲得的entry就是這個鏈的第一個節點，若是e!=null，說明找到了，這是就要替換節點的值（onlyIfAbsent == false），不然，咱們須要new一個entry，它的後繼是first，而讓tab[index]指向它，什麼意思呢？實際上就是將這個新entry插入到鏈頭，剩下的就很是容易理解了。

6、ConcurrentHashMap的remove操做

Remove操做的前面一部分和前面的get和put操做同樣，都是定位Segment的過程，而後再調用Segment的remove方法：

V remove(Object key, int hash, Object value) { 
    lock(); 
    try { 
        int c = count - 1; 
        HashEntry<K,V>[] tab = table; 
        int index = hash & (tab.length - 1); 
        HashEntry<K,V> first = tab[index]; 
        HashEntry<K,V> e = first; 
        while (e != null && (e.hash != hash || !key.equals(e.key))) 
            e = e.next; 
   
        V oldValue = null; 
        if (e != null) { 
            V v = e.value; 
            if (value == null || value.equals(v)) { 
                oldValue = v; 
                // All entries following removed node can stay 
                // in list, but all preceding ones need to be 
                // cloned. 
                ++modCount; 
                HashEntry<K,V> newFirst = e.next; 
                for (HashEntry<K,V> p = first; p != e; p = p.next) 
                    newFirst = new HashEntry<K,V>(p.key, p.hash, 
                                                  newFirst, p.value); 
                tab[index] = newFirst; 
                count = c; // write-volatile 
            } 
        } 
        return oldValue; 
    } finally { 
        unlock(); 
    } 
}

首先remove操做也是肯定須要刪除的元素的位置，不過這裏刪除元素的方法不是簡單地把待刪除元素的前面的一個元素的next指向後面一個就完事了，咱們以前已經說過HashEntry中的next是final的，一經賦值之後就不可修改，在定位到待刪除元素的位置之後，程序就將待刪除元素前面的那一些元素所有複製一遍，而後再一個一個從新接到鏈表上去，看一下下面這一幅圖來了解這個過程：
249993-20170912135512172-986817539.png

假設鏈表中原來的元素如上圖所示，如今要刪除元素3，那麼刪除元素3之後的鏈表就以下圖所示：
249993-20170912135542141-563857047.png

整個操做是在持有段鎖的狀況下執行的，空白行以前(第11行以前)的行主要是定位到要刪除的節點e。接下來，若是不存在這個節點就直接返回null，不然就要將e前面的結點複製一遍，尾結點指向e的下一個結點。e後面的結點不須要複製，它們能夠重用。
中間那個for循環是作什麼用的呢？（第22行）從代碼來看，就是將定位以後的全部entry克隆並拼回前面去，但有必要嗎？每次刪除一個元素就要將那以前的元素克隆一遍？這點實際上是由entry的不變性來決定的，仔細觀察entry定義，發現除了value，其餘全部屬性都是用final來修飾的，這意味着在第一次設置了next域以後便不能再改變它，取而代之的是將它以前的節點全都克隆一次。至於entry爲何要設置爲不變性，這跟不變性的訪問不須要同步從而節省時間有關。
整個remove實現並不複雜，可是須要注意以下幾點。第一，當要刪除的結點存在時，刪除的最後一步操做要將count的值減一。這必須是最後一步操做，不然讀取操做可能看不到以前對段所作的結構性修改。第二，remove執行的開始就將table賦給一個局部變量tab，這是由於table是 volatile變量，讀寫volatile變量的開銷很大。編譯器也不能對volatile變量的讀寫作任何優化，直接屢次訪問非volatile實例變量沒有多大影響，編譯器會作相應優化。

7、總結

ConcurrentHashMap背景：出現的緣由是由於咱們起先使用的是HashMap和HashTable，可是隨着併發量的增長，HashMap並無使用同步，在多線程狀況下使用HashMap的時候就會出現併發問題，而HashTable雖然是安全的，可是使用的是synchronized 鎖整表操做，這樣在性能上將會產生很大的影響。那麼如何能設計出一款即安全，在效率上又高的集合呢，這樣就有了ConcurrentHashMap的產生。ConcurrentHashMap採用的是鎖分段技術，內部爲Segment數組來進行細分，而每一個Segment又經過HashEntry數組來進行組裝，當進行寫操做的時候，只須要對這個key對應的Segment進行加鎖操做，加鎖同時不會對其餘的Segment形成影響。總的Map包含了16個Segment（默認數量），每一個Segment內部包含16個HashEntry（默認數量），這樣對於這個key所在的Segment加鎖的同時，其餘15個Segmeng還能正常使用，在性能上有了大大的提高。同時ConcurrentHashMap只是針對put方法進行了加鎖，而對於get方法並無採用加鎖的操做，由於具體的值，在Segment的HashEntry裏面是volatile的，基於happens-before（先行發生）原則，對數據的寫先行發生於對數據的讀，因此再讀取的時候獲取到的必然是最新的結果。由於對數組的操做，在主內存和工做內存中，load和use、assgin和store是必然連在一塊兒的，一旦使用（use）發生，那load必先行發生於use以前，use前必然從主內存中加載最新的值到工做內存的變量副本里。而一旦賦值（assgin），必然先行發生於store將值傳遞給主內存，在write到主內存中去。因此put方式無需加鎖也能獲取到最新的結果。size操做是先請求2次的count數量，若是有發生變化，則對put、remove、clean進行加鎖，在統計完以後unlock。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程