主要參考:http://www.cnblogs.com/leesf456/p/5453341.html
http://blog.csdn.net/sunyangwei1993/article/details/77001597
一、前言
最近幾天忙着做點別的東西,今天終於有時間分析源碼了,看源碼感覺很爽,並且發現ConcurrentHashMap在JDK1.8版本與之前的版本在併發控制上存在很大的差別,很有必要進行認真的分析,下面進行源碼分析。
二、ConcurrentHashMap數據結構(jdk1.8)
之前已經提及過,ConcurrentHashMap相比HashMap而言,是多線程安全的,其底層數據與HashMap的數據結構相同,數據結構如下
說明:ConcurrentHashMap的數據結構(數組+鏈表+紅黑樹),桶中的結構可能是鏈表,也可能是紅黑樹,紅黑樹是爲了提高查找效率。
三、ConcurrentHashMap源碼分析(jdk1.8)
3.1 類的繼承關係
public class ConcurrentHashMap<K,V> extends AbstractMap<K,V> implements ConcurrentMap<K,V>, Serializable {}
說明:ConcurrentHashMap繼承了AbstractMap抽象類,該抽象類定義了一些基本操作,同時,也實現了ConcurrentMap接口,ConcurrentMap接口也定義了一系列操作,實現了Serializable接口表示ConcurrentHashMap可以被序列化。
3.2 類的內部類
ConcurrentHashMap包含了很多內部類,其中主要的內部類框架圖如下圖所示
說明:可以看到,ConcurrentHashMap的內部類非常的龐大,第二個圖是在JDK1.8下增加的類。
下面對主要的內部類進行分析和講解。
1. Node類
Node類主要用於存儲具體鍵值對,其子類有ForwardingNode、ReservationNode、TreeNode和TreeBin四個子類。四個子類具體的代碼在之後的具體例子中進行分析講解。
2. Traverser類
Traverser類主要用於遍歷操作,其子類有BaseIterator、KeySpliterator、ValueSpliterator、EntrySpliterator四個類,BaseIterator用於遍歷操作。KeySplitertor、ValueSpliterator、EntrySpliterator則用於鍵、值、鍵值對的劃分。
3. CollectionView類
CollectionView抽象類主要定義了視圖操作,其子類KeySetView、ValueSetView、EntrySetView分別表示鍵視圖、值視圖、鍵值對視圖。對視圖均可以進行操作。
4. Segment類
Segment類在JDK1.8中與之前的版本的JDK作用存在很大的差別,JDK1.8下,其在普通的ConcurrentHashMap操作中已經沒有失效,其在序列化與反序列化的時候會發揮作用。
5. CounterCell
CounterCell類主要用於對baseCount的計數。
3.3 類的屬性
public class ConcurrentHashMap<K,V> extends AbstractMap<K,V> implements ConcurrentMap<K,V>, Serializable { private static final long serialVersionUID = 7249069246763182397L;
// 表的最大容量 private static final int MAXIMUM_CAPACITY = 1 << 30; // 默認表的大小 private static final int DEFAULT_CAPACITY = 16; // 最大數組大小 static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; // 默認併發數 private static final int DEFAULT_CONCURRENCY_LEVEL = 16; // 裝載因子 private static final float LOAD_FACTOR = 0.75f; // 轉化爲紅黑樹的閾值 static final int TREEIFY_THRESHOLD = 8; // 由紅黑樹轉化爲鏈表的閾值 static final int UNTREEIFY_THRESHOLD = 6; // 轉化爲紅黑樹的表的最小容量 static final int MIN_TREEIFY_CAPACITY = 64; // 每次進行轉移的最小值 private static final int MIN_TRANSFER_STRIDE = 16; // 生成sizeCtl所使用的bit位數 private static int RESIZE_STAMP_BITS = 16; // 進行擴容所允許的最大線程數 private static final int MAX_RESIZERS = (1 << (32 - RESIZE_STAMP_BITS)) - 1; // 記錄sizeCtl中的大小所需要進行的偏移位數 private static final int RESIZE_STAMP_SHIFT = 32 - RESIZE_STAMP_BITS; // 一系列的標識 static final int MOVED = -1; // hash for forwarding nodes static final int TREEBIN = -2; // hash for roots of trees static final int RESERVED = -3; // hash for transient reservations static final int HASH_BITS = 0x7fffffff; // usable bits of normal node hash // /** Number of CPUS, to place bounds on some sizings */ // 獲取可用的CPU個數 static final int NCPU = Runtime.getRuntime().availableProcessors(); // /** For serialization compatibility. */ // 進行序列化的屬性 private static final ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("segments", Segment[].class), new ObjectStreamField("segmentMask", Integer.TYPE), new ObjectStreamField("segmentShift", Integer.TYPE) }; // 表 transient volatile Node<K,V>[] table; // 下一個表 private transient volatile Node<K,V>[] nextTable; // /** * Base counter value, used mainly when there is no contention, * but also as a fallback during table initialization * races. Updated via CAS. */ // 基本計數 private transient volatile long baseCount; // /** * Table initialization and resizing control. When negative, the * table is being initialized or resized: -1 for initialization, * else -(1 + the number of active resizing threads). Otherwise, * when table is null, holds the initial table size to use upon * creation, or 0 for default. After initialization, holds the * next element count value upon which to resize the table. */ // 對錶初始化和擴容控制 private transient volatile int sizeCtl; /** * The next table index (plus one) to split while resizing. */ // 擴容下另一個表的索引 private transient volatile int transferIndex; /** * Spinlock (locked via CAS) used when resizing and/or creating CounterCells. */ // 旋轉鎖 private transient volatile int cellsBusy; /** * Table of counter cells. When non-null, size is a power of 2. */ // counterCell表 private transient volatile CounterCell[] counterCells; // views // 視圖 private transient KeySetView<K,V> keySet; private transient ValuesView<K,V> values; private transient EntrySetView<K,V> entrySet; // Unsafe mechanics private static final sun.misc.Unsafe U; private static final long SIZECTL; private static final long TRANSFERINDEX; private static final long BASECOUNT; private static final long CELLSBUSY; private static final long CELLVALUE; private static final long ABASE; private static final int ASHIFT; static { try { U = sun.misc.Unsafe.getUnsafe(); Class<?> k = ConcurrentHashMap.class; SIZECTL = U.objectFieldOffset (k.getDeclaredField("sizeCtl")); TRANSFERINDEX = U.objectFieldOffset (k.getDeclaredField("transferIndex")); BASECOUNT = U.objectFieldOffset (k.getDeclaredField("baseCount")); CELLSBUSY = U.objectFieldOffset (k.getDeclaredField("cellsBusy")); Class<?> ck = CounterCell.class; CELLVALUE = U.objectFieldOffset (ck.getDeclaredField("value")); Class<?> ak = Node[].class; ABASE = U.arrayBaseOffset(ak); int scale = U.arrayIndexScale(ak); if ((scale & (scale - 1)) != 0) throw new Error("data type scale not a power of two"); ASHIFT = 31 - Integer.numberOfLeadingZeros(scale); } catch (Exception e) { throw new Error(e); } } }
說明:ConcurrentHashMap的屬性很多,其中不少屬性在HashMap中就已經介紹過,而對於ConcurrentHashMap而言,添加了Unsafe實例,主要用於反射獲取對象相應的字段,需要注意的是
transient volatile Node<K,V>[] table;
這裏Node用了transient volatile來保證
3.4 類的構造函數
1. ConcurrentHashMap()型構造函數
public ConcurrentHashMap() { }
說明:該構造函數用於創建一個帶有默認初始容量 (16)、加載因子 (0.75) 和 concurrencyLevel (16) 的新的空映射。
2. ConcurrentHashMap(int)型構造函數
public ConcurrentHashMap(int initialCapacity) { if (initialCapacity < 0) // 初始容量小於0,拋出異常 throw new IllegalArgumentException(); int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ? MAXIMUM_CAPACITY : tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1)); // 找到最接近該容量的2的冪次方數 // 初始化 this.sizeCtl = cap; }
說明:該構造函數用於創建一個帶有指定初始容量、默認加載因子 (0.75) 和 concurrencyLevel (16) 的新的空映射。
3. ConcurrentHashMap(Map<? extends K, ? extends V>)型構造函數
public ConcurrentHashMap(Map<? extends K, ? extends V> m) { this.sizeCtl = DEFAULT_CAPACITY; // 將集合m的元素全部放入 putAll(m); }
說明:該構造函數用於構造一個與給定映射具有相同映射關係的新映射。
4. ConcurrentHashMap(int, float)型構造函數
public ConcurrentHashMap(int initialCapacity, float loadFactor) { this(initialCapacity, loadFactor, 1); }
說明:該構造函數用於創建一個帶有指定初始容量、加載因子和默認 concurrencyLevel (1) 的新的空映射。
5. ConcurrentHashMap(int, float, int)型構造函數
public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) { if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0) // 合法性判斷 throw new IllegalArgumentException(); if (initialCapacity < concurrencyLevel) // Use at least as many bins initialCapacity = concurrencyLevel; // as estimated threads long size = (long)(1.0 + (long)initialCapacity / loadFactor); int cap = (size >= (long)MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : tableSizeFor((int)size); this.sizeCtl = cap; }
說明:該構造函數用於創建一個帶有指定初始容量、加載因子和併發級別的新的空映射。
對於構造函數而言,會根據輸入的initialCapacity的大小來確定一個最小的且大於等於initialCapacity大小的2的n次冪,如initialCapacity爲15,則sizeCtl爲16,若initialCapacity爲16,則sizeCtl爲16。若initialCapacity大小超過了允許的最大值,則sizeCtl爲最大值。值得注意的是,構造函數中的concurrencyLevel參數已經在JDK1.8中的意義發生了很大的變化,其並不代表所允許的併發數,其只是用來確定sizeCtl大小,在JDK1.8中的併發控制都是針對具體的桶而言,即有多少個桶就可以允許多少個併發數。
這時候我們先來回顧一下JDK1.7中的CocurrentHashMap:
HashMap的容量由負載因子決定,插入的元素超過了容量的範圍就會觸發擴容操作,就是rehash。
在多線程環境下,若同時存在其他元素進行put操作,如果hash值相同,可能出現在同一數組下用鏈表表示,出現閉環,導致在get的操作會出現死循環,所以hashmap是線程不安全的。
Hashtable是線程安全的,它在所有都涉及到多線程操作時都加了synchronized關鍵字來鎖住整個table,意味着所有線程都在爭用一把鎖,在多線程的環境下,它是安全的,但效率低下。
ConcurrentHashMap採用鎖分離技術,將鎖的粒度降低,利用多個鎖來控制多個小的table。
ConcurrentHashMap的數據結構是由一個Segment數組和多個HashEntry組成,如下圖所示:
Segment數組的意義就是將一個大的table分割成多個小的table來進行加鎖,也就是上面的提到的鎖分離技術,而每一個Segment元素存儲的是HashEntry數組+鏈表,這個和HashMap的數據存儲結構一樣。
ConcurrentHashMap的初始化是會通過位與運算來初始化Segment的大小,用ssize來表示,如下所示
如上所示,因爲ssize用位於運算來計算(ssize <<=1),所以Segment的大小取值都是以2的N次方,無關concurrencyLevel的取值,當然concurrencyLevel最大隻能用16位的二進制來表示,即65536,換句話說,Segment的大小最多65536個,沒有指定concurrencyLevel元素初始化,Segment的大小ssize默認爲16。
每一個Segment元素下的HashEntry的初始化也是按照位於運算來計算,用cap來表示,如下所示
如上所示,HashEntry大小的計算也是2的N次方(cap <<=1), cap的初始值爲1,所以HashEntry最小的容量爲2。
put操作
對於ConcurrentHashMap的數據插入,這裏要進行兩次Hash去定位數據的存儲位置
從上Segment的繼承體系可以看出,Segment實現了ReentrantLock,也就帶有鎖的功能,當執行put操作時,會進行第一次key的hash來定位Segment的位置,如果該Segment還沒有初始化,即通過CAS操作進行賦值,然後進行第二次hash操作,找到相應的HashEntry的位置,這裏會利用繼承過來的鎖的特性,在將數據插入指定的HashEntry位置時(鏈表的尾端),會通過繼承ReentrantLock的tryLock()方法嘗試去獲取鎖,如果獲取成功就直接插入相應的位置,如果已經有線程獲取該Segment的鎖,那當前線程會以自旋的方式去繼續的調用tryLock()方法去獲取鎖,超過指定次數就掛起,等待喚醒。
get操作
ConcurrentHashMap的get操作跟HashMap類似,只是首先要判斷volatile類型變量count是否不等於0,若不等於0則ConcurrentHashMap第一次需要經過一次hash定位到Segment的位置,然後再hash定位到指定的HashEntry,遍歷該HashEntry下的鏈表進行對比,成功就返回,不成功就返回null。是弱一致性的。
因爲count是volatile,所以對count的寫要happens-before於讀操作。寫線程 M 對鏈表做的結構性修改,在讀線程 N 讀取了同一個 volatile 變量後,對線程 N 也是可見的了。雖然線程 N 是在未加鎖的情況下訪問鏈表。Java 的內存模型可以保證:只要之前對鏈表做結構性修改操作的寫線程 M 在退出寫方法前寫 volatile 型變量 count,讀線程 N 在讀取這個 volatile 型變量 count 後,就一定能“看到”這些修改。使得在 ConcurrentHashMap 中,讀線程在讀取散列表時,基本不需要加鎖就能成功獲得需要的值,不僅減少了請求同一個鎖的頻率(讀操作一般不需要加鎖就能夠成功獲得值),也減少了持有同一個鎖的時間(只有讀到 value 域的值爲 null 時 , 讀線程才需要加鎖後重讀)。
size操作
計算ConcurrentHashMap的元素大小是一個有趣的問題,因爲他是併發操作的,就是在你計算size的時候,他還在併發的插入數據,可能會導致你計算出來的size和你實際的size有相差(在你return size的時候,插入了多個數據),要解決這個問題,JDK1.7版本用兩種方案。
- 第一種方案他會使用不加鎖的模式去嘗試多次計算ConcurrentHashMap的size,最多三次,比較前後兩次計算的結果,結果一致就認爲當前沒有元素加入,計算的結果是準確的;
- 第二種方案是如果第一種方案不符合,他就會給每個Segment加上鎖,然後計算ConcurrentHashMap的size返回。
在JDK1.8中:
改變了HashMap的索引方法,詳見JDK1.8之HashMap,在put時並不會導致鏈表死循環,但依然不能保證HashMap的線程安全,即是多線程put的時候,當index相同而又同時達到鏈表的末尾時,另一個線程put的數據會把之前線程put的數據覆蓋掉,就會產生數據丟失。
JDK1.8的實現已經摒棄了Segment的概念,而是直接用Node數組+鏈表+紅黑樹的數據結構來實現,併發控制使用Synchronized和CAS來操作,整個看起來就像是優化過且線程安全的HashMap,雖然在JDK1.8中還能看到Segment的數據結構,但是已經簡化了屬性,只是爲了兼容舊版本,序列化與反序列化的時候會發揮作用。
Node
Node是ConcurrentHashMap存儲結構的基本單元,繼承於HashMap中的Entry,用於存儲數據,源代碼如下
Node數據結構很簡單,它與HashMap中的定義很相似,但是但是有一些差別它對value和next屬性設置了volatile同步鎖,它不允許調用setValue方法直接改變Node的value域,它增加了find方法輔助map.get()方法。
TreeNode
TreeNode繼承與Node,但是數據結構換成了二叉樹結構,它是紅黑樹的數據的存儲結構,用於紅黑樹中存儲數據,當鏈表的節點數大於8時會轉換成紅黑樹的結構,樹節點類,另外一個核心的數據結構。當鏈表長度過長的時候,會轉換爲TreeNode。但是與HashMap不相同的是,它並不是直接轉換爲紅黑樹,而是把這些結點包裝成TreeNode放在TreeBin對象中,由TreeBin完成對紅黑樹的包裝。而且TreeNode在ConcurrentHashMap集成自Node類,而並非HashMap中的集成自LinkedHashMap.Entry<K,V>類,也就是說TreeNode帶有next指針,這樣做的目的是方便基於TreeBin的訪問。
TreeBin
TreeBin從字面含義中可以理解爲存儲樹形結構的容器,而樹形結構就是指TreeNode,所以TreeBin就是封裝TreeNode的容器,它提供轉換黑紅樹的一些條件和鎖的控制。這個類並不負責包裝用戶的key、value信息,而是包裝的很多TreeNode節點。它代替了TreeNode的根節點,也就是說在實際的ConcurrentHashMap“數組”中,存放的是TreeBin對象,而不是TreeNode對象,這是與HashMap的區別。另外這個類還帶有了讀寫鎖。
ForwardingNode
一個用於連接兩個table的節點類。它包含一個nextTable指針,用於指向下一張表。而且這個節點的key value next指針全部爲null,它的hash值爲-1. 這裏面定義的find的方法是從nextTable裏進行查詢節點,而不是以自身爲頭節點進行查找
Unsafe與CAS
在ConcurrentHashMap中,隨處可以看到U, 大量使用了U.compareAndSwapXXX的方法,這個方法是利用一個CAS算法實現無鎖化的修改值的操作,他可以大大降低鎖代理的性能消耗。這個算法的基本思想就是不斷地去比較當前內存中的變量值與你指定的一個變量值是否相等,如果相等,則接受你指定的修改的值,否則拒絕你的操作。因爲當前線程中的值已經不是最新的值,你的修改很可能會覆蓋掉其他線程修改的結果。這一點與樂觀鎖,SVN的思想是比較類似的。
unsafe靜態塊
unsafe代碼塊控制了一些屬性的修改工作,比如最常用的SIZECTL 。 在這一版本的concurrentHashMap中,大量應用來的CAS方法進行變量、屬性的修改工作。 利用CAS進行無鎖操作,可以大大提高性能。
介紹了ConcurrentHashMap主要的屬性與內部的數據結構,現在通過一個簡單的例子以debug的視角看看ConcurrentHashMap的具體操作細節。
先通過new ConcurrentHashMap()來進行初始化
由上你會發現ConcurrentHashMap的初始化其實是一個空實現,並沒有做任何事,這裏後面會講到,這也是和其他的集合類有區別的地方,初始化操作並不是在構造函數實現的,而是在put操作中實現,當然ConcurrentHashMap還提供了其他的構造函數。
put操作
在上面的例子中我們新增個人信息會調用put方法,我們來看下。
ConcurrentHashMap不允許key或value爲null值
這個put的過程很清晰,對當前的table進行無條件自循環直到put成功,可以分成以下六步流程來概述。
① 判斷存儲的key、value是否爲空,若爲空,則拋出異常,否則,進入步驟②
② 計算key的hash值,隨後進入無限循環,該無限循環可以確保成功插入數據,若table表爲空或者長度爲0,則初始化table表,否則,進入步驟③
③ 根據key的hash值取出table表中的結點元素,若取出的結點爲空(該桶爲空),則使用CAS將key、value、hash值生成的結點放入桶中。否則,進入步驟④
④ 若該結點的的hash值爲MOVED,則對該桶中的結點進行轉移,即該線程幫助其進行擴容。否則,進入步驟⑤
⑤ 對桶中的第一個結點(即table表中的結點)進行加鎖,對該桶進行遍歷,桶中的結點的hash值與key值與給定的hash值和key值相等,則根據標識選擇是否進行更新操作(用給定的value值替換該結點的value值),若遍歷完桶仍沒有找到hash值與key值和指定的hash值與key值相等的結點,則直接新生一個結點並賦值爲之前最後一個結點的下一個結點。進入步驟⑥
⑥ 若binCount值達到紅黑樹轉化的閾值,則將桶中的結構轉化爲紅黑樹存儲,最後,增加binCount的值。
其中:
helpTransfer()方法的目的就是調用多個工作線程一起幫助進行擴容,這樣的效率就會更高,而不是隻有檢查到要擴容的那個線程進行擴容操作,其他線程就要等待擴容操作完成才能工作。 幫助從舊的table的元素複製到新的table中,新的table即nextTba已經存在前提下才能幫助擴容。
擴容過程有點複雜,這裏主要涉及到多線程併發擴容,ForwardingNode的作用就是支持擴容操作,將已處理的節點和空節點置爲ForwardingNode,併發處理時多個線程經過ForwardingNode就表示已經遍歷了,就往後遍歷,下圖是多線程合作擴容的過程:
在併發處理中使用的是樂觀鎖,當有衝突的時候才進行併發處理,而且流程步驟很清晰,但是細節設計的很複雜,畢竟多線程的場景也複雜。
擴容方法 transfer()
當ConcurrentHashMap容量不足的時候,需要對table進行擴容。這個方法的基本思想跟HashMap是很像的,但是由於它是支持併發擴容的,所以要複雜的多。原因是它支持多線程進行擴容操作,而並沒有加鎖。我想這樣做的目的不僅僅是爲了滿足concurrent的要求,而是希望利用併發處理去減少擴容帶來的時間影響。因爲在擴容的時候,總是會涉及到從一個“數組”到另一個“數組”拷貝的操作,如果這個操作能夠併發進行,那真真是極好的了。
整個擴容操作分爲兩個部分-
第一部分是構建一個nextTable,它的容量是原來的兩倍,這個操作是單線程完成的。這個單線程的保證是通過RESIZE_STAMP_SHIFT這個常量經過一次運算來保證的,這個地方在後面會有提到;
- 第二個部分就是將原來table中的元素複製到nextTable中,這裏允許多線程進行操作。
先來看一下單線程是如何完成的:
它的大體思想就是遍歷、複製的過程。首先根據運算得到需要遍歷的次數i,然後利用tabAt方法獲得i位置的元素:
-
如果這個位置爲空,就在原table中的i位置放入forwardNode節點,這個也是觸發併發擴容的關鍵點;
-
如果這個位置是Node節點(fh>=0),如果它是一個鏈表的頭節點,就構造一個反序鏈表,把他們分別放在nextTable的i和i+n的位置上
-
如果這個位置是TreeBin節點(fh<0),也做一個反序處理,並且判斷是否需要untreefi,把處理的結果分別放在nextTable的i和i+n的位置上
- 遍歷過所有的節點以後就完成了複製工作,這時讓nextTable作爲新的table,並且更新sizeCtl爲新容量的0.75倍 ,完成擴容。
在代碼的69行有一個判斷,如果遍歷到的節點是forward節點,就向後繼續遍歷,再加上給節點上鎖的機制,就完成了多線程的控制。多線程遍歷節點,處理了一個節點,就把對應點的值set爲forward,另一個線程看到forward,就向後遍歷。這樣交叉就完成了複製工作。而且還很好的解決了線程安全的問題。 這個方法的設計實在是讓我膜拜。
get操作
使用String name = map.get(“name”)獲取新增的name信息,現在我們依舊用debug的方式來分析下ConcurrentHashMap的獲取方法get()
ConcurrentHashMap的get操作的流程很簡單,也很清晰,可以分爲三個步驟來描述:
1. 計算hash值,定位到該table索引位置,如果是首節點符合就返回
2. 如果遇到擴容的時候,會調用標誌正在擴容節點ForwardingNode的find方法,查找該節點,匹配就返回
3. 以上都不符合的話,就往下遍歷節點,匹配就返回,否則最後就返回null
這個get請求,我們需要cas來保證變量的原子性。如果tab[i]正被鎖住,那麼CAS就會失敗,失敗之後就會不斷的重試。這也保證了get在高併發情況下不會出錯。我們來分析下到底有多少種情況會導致get在併發的情況下可能取不到值。1、一個線程在get的時候,另一個線程在對同一個key的node進行remove操作;2、一個線程在get的時候,另一個線程正則重排table。可能導致舊table取不到值。那麼本質是,我在get的時候,有其他線程在對同一桶的鏈表或樹進行修改。那麼get是怎麼保證同步性的呢?我們看到e = tabAt(tab, (n - 1) & h)) != null,在看下tablAt到底是幹嘛的:
static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
}
它是對tab[i]進行原子性的讀取,因爲我們知道putVal等對table的桶操作是有加鎖的,那麼一般情況下我們對桶的讀也是要加鎖的,但是我們這邊爲什麼不需要加鎖呢?因爲我們用了Unsafe的getObjectVolatile,因爲table是volatile類型,所以對tab[i]的原子請求也是可見的。因爲如果同步正確的情況下,根據happens-before原則,對volatile域的寫入操作happens-before於每一個後續對同一域的讀操作。所以不管其他線程對table鏈表或樹的修改,都對get讀取可見。
size操作
最後我們來看下例子中最後獲取size的方式int size = map.size();,現在讓我們看下size()方法:
在JDK1.8版本中,對於size的計算,在擴容和addCount()方法就已經有處理了,JDK1.7是在調用size()方法纔去計算,其實在併發集合中去計算size是沒有多大的意義的,因爲size是實時在變的,只能計算某一刻的大小,但是某一刻太快了,人的感知是一個時間段,所以並不是很精確。
總結與思考
其實可以看出JDK1.8版本的ConcurrentHashMap的數據結構已經接近HashMap,相對而言,ConcurrentHashMap只是增加了同步的操作來控制併發,從JDK1.7版本的ReentrantLock+Segment+HashEntry,到JDK1.8版本中synchronized+CAS+HashEntry+紅黑樹,相對而言,總結如下思考:
1. JDK1.8的實現降低鎖的粒度,JDK1.7版本鎖的粒度是基於Segment的,包含多個HashEntry,而JDK1.8鎖的粒度就是HashEntry(首節點)
2. JDK1.8版本的數據結構變得更加簡單,使得操作也更加清晰流暢,因爲已經使用synchronized來進行同步,所以不需要分段鎖的概念,也就不需要Segment這種數據結構了,由於粒度的降低,實現的複雜度也增加了
3. JDK1.8使用紅黑樹來優化鏈表,基於長度很長的鏈表的遍歷是一個很漫長的過程,而紅黑樹的遍歷效率是很快的,代替一定閾值的鏈表,這樣形成一個最佳拍檔
4. JDK1.8爲什麼使用內置鎖synchronized來代替重入鎖ReentrantLock,我覺得有以下幾點:因爲粒度降低了,在相對而言的低粒度加鎖方式,synchronized並不比ReentrantLock差,在粗粒度加鎖中ReentrantLock可能通過Condition來控制各個低粒度的邊界,更加的靈活,而在低粒度中,Condition的優勢就沒有了
5. JVM的開發團隊從來都沒有放棄synchronized,而且基於JVM的synchronized優化空間更大,使用內嵌的關鍵字比使用API更加自然
6. 在大量的數據操作下,對於JVM的內存壓力,基於API的ReentrantLock會開銷更多的內存,雖然不是瓶頸,但是也是一個選擇依據