簡述
一說到HashMap與Hashtable區別就會想到前者執行緒不安全,後者執行緒安全。但是當我們需要執行緒安全的時候,Hashtable並不是一個良好的選擇,concurrentHashMap才是。
為什麼使用concurrentHashMap
得到執行緒安全的HashMap有以下三種方式:
①.使用Hashtable
②.使用Collections.synchronizedMap()方法
③.使用concurrentHashMap
有這3中方式,為什麼推薦使用第三種,而不是其餘兩個方法?答案:效率,我們來看看那兩種方式的原始碼
我們可以看到Hashtable用synchronized關鍵字來保證執行緒安全,鎖住當前例項物件,即每次只有一個執行緒能訪問此物件,線上程競爭激烈的情況下,這種方法效率非常低。
public static Map synchronizedMap(Map m) { return new SynchronizedMap<>(m); }
private static class SynchronizedMap<K,V> implements Map<K,V>, Serializable { private final Map<K,V> m; // Backing Map final Object mutex; // Object on which to synchronize SynchronizedMap(Map<K,V> m) { this.m = Objects.requireNonNull(m); mutex = this; } public int size() { synchronized (mutex) {return m.size();} } public boolean isEmpty() { synchronized (mutex) {return m.isEmpty();} } public boolean containsKey(Object key) { synchronized (mutex) {return m.containsKey(key);} } 複製程式碼
複製程式碼
複製程式碼
我們可以看到也使用synchronized關鍵字將HashMap包裝成一個執行緒安全的map與Hashtable類似,每次只有一個執行緒能訪問此物件。
而ConcurrentHashMap jdk1.7中採用了分段鎖技術,其中 Segment 繼承於 ReentrantLock。不會像 HashTable 那樣不管是 put 還是 get 操作都需要做同步處理。jdk1.8中放棄了 Segment 分段鎖,採用了CAS + synchronized來保證執行緒安全。
ConcurrentHashMap(JDK 1.8)解析
屬性
/** * 存放node的陣列,大小是2的冪次方 */ transient volatile Node[] table; /** * 擴容時用於存放資料的變數,平時為null */ private transient volatile Node[] nextTable; /** * 通過CAS更新,記錄容器的容量大小 */ private transient volatile long baseCount; /** * 控制標誌符 * 負數: 代表正在進行初始化或擴容操作,其中-1表示正在初始化,-N 表示有N-1個執行緒正在進行擴容操作 * 正數或0: 代表hash表還沒有被初始化,這個數值表示初始化或下一次進行擴容的大小,類似於擴容閾值 * 它的值始終是當前ConcurrentHashMap容量的0.75倍,這與loadfactor是對應的。 * 實際容量 >= sizeCtl,則擴容 */ private transient volatile int sizeCtl; /** * 下次transfer方法的起始下標index加上1之後的值 */ private transient volatile int transferIndex; /** * CAS自旋鎖標誌位 */ private transient volatile int cellsBusy; /** * counter cell表,長度總為2的冪次 */ private transient volatile CounterCell[] counterCells; 複製程式碼
重要內部類
與jdk1.8中HashMap中的定義很相似,不過value和next屬性用volatile修飾保證了記憶體可見性,沒有setValue方法直接改變Node的value屬性
static class Node implements Map.Entry {
final int hash;
final K key;
volatile V val;
volatile Node next;
...
}
複製程式碼
HashMap採用了紅黑樹+陣列+連結串列的形式,ConcurrentHashMap與其資料結構類似。TreeNode為TreeBin內部類服務,雜湊值固定值為-2
static final class TreeNode extends LinkedHashMap.Entry {
TreeNode parent; // red-black tree links
TreeNode left;
TreeNode right;
TreeNode prev; // needed to unlink next upon deletion
boolean red;
...
}
複製程式碼
static final class TreeBin extends Node {
TreeNode root;
volatile TreeNode first;
volatile Thread waiter;
volatile int lockState;
// values for lockState
static final int WRITER = 1; // set while holding write lock
static final int WAITER = 2; // set when waiting for write lock
static final int READER = 4; // increment value for setting read lock
...
}
複製程式碼
ForwardingNode是一種臨時節點只有擴容時使用,表明當前桶已做過處理
static final class ForwardingNode extends Node {
final Node[] nextTable;
//ForwardingNode節點hash為-1,若操作中遇到此型別節點,表明有執行緒正在擴容
ForwardingNode(Node[] tab) {
super(MOVED, null, null, null);
this.nextTable = tab;
}
...
}
複製程式碼
構造方法
/**
* 預設構造方法
*/
public ConcurrentHashMap() {}
/**
* 指定容量
*/
public ConcurrentHashMap(int initialCapacity) {
//異常情況
if (initialCapacity < 0)
throw new IllegalArgumentException();
//計算容量
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ?
MAXIMUM_CAPACITY :
tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
this.sizeCtl = cap;
}
/**
* 指定map
*/
public ConcurrentHashMap(Map m) {
this.sizeCtl = DEFAULT_CAPACITY;
putAll(m);
}
/**
* 指定容量、負載因子
*/
public ConcurrentHashMap(int initialCapacity, float loadFactor) {
this(initialCapacity, loadFactor, 1);
}
/**
* 指定容量、負載因子、併發級別
*/
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;
}
複製程式碼
CAS操作
concurrentHashMap呼叫Unsafe類中的方法實現CAS(這個演算法的基本思想就是不斷地去比較當前記憶體中的變數值與你指定的一個變數值是否相等,如果相等,則接受你指定的修改的值,否則拒絕你的操作),其內部方法大多為native方法即直接呼叫作業系統底層資源執行相應任務,提供了一些可以直接操控記憶體和執行緒的底層操作。
initTable方法
initTable方法判斷sizeCtl值,若sizeCtl值為-1即有其他執行緒正在初始化,呼叫Thread.yield()讓出CPU時間片,而正在初始化的執行緒通過Unsafe.compareAndSwapInt方法修改sizeCtl為-1,初始化陣列和擴容閾值。
private final Node[] initTable() {
Node[] tab; int sc;
while ((tab = table) == null || tab.length == 0) {
//若sizeCtl<0,即存在其他執行緒正在初始化操作,確保只有一個執行緒進行初始化
if ((sc = sizeCtl) < 0)
Thread.yield(); // lost initialization race; just spin
//利用CAS方法把sizectl的值置為-1,表明已有執行緒進行初始化
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
if ((tab = table) == null || tab.length == 0) {
//獲得桶容量
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
//初始化node陣列
Node[] nt = (Node[])new Node[n];
table = tab = nt;
//計算擴容閾值0.75n
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
複製程式碼
從原始碼我們可以看出最外層的流程控制採用while迴圈,而非if條件分支,因為Thread.yield()會讓出cpu時間,目的在於確保陣列初始化成功
put方法
ConcurrentHashMap的put操作與HashMap很相似,但ConcurrentHashMap不允許null作為key和value,並且由於需要保證執行緒安全,有以下兩個多執行緒情況:
①.如果一個或多個執行緒正在對ConcurrentHashMap進行擴容操作,當前執行緒也要進入擴容的操作中。這個擴容的操作之所以能被檢測到,是因為transfer方法會將已經操作過擴容桶頭結點置為ForwardingNode節點,如果檢測到需要插入的位置被該節點佔有,就幫助進行擴容。
②.如果檢測到要插入的節點是非空且不是ForwardingNode節點,就對這個節點加鎖,這樣就保證了執行緒安全。
final V putVal(K key, V value, boolean onlyIfAbsent) {
//與HashMap不同,ConcurrentHashMap不允許null作為key或value
if (key == null || value == null) throw new NullPointerException();
//計算hash值
int hash = spread(key.hashCode());
int binCount = 0;
for (Node[] tab = table;;) {
Node f; int n, i, fh;
//若table為空的話,初始化table
if (tab == null || (n = tab.length) == 0)
tab = initTable();
//若當前陣列i位置上的節點為null
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
//CAS插入節點(V:當前陣列i位置上的節點; O:null; N:新Node物件)
if (casTabAt(tab, i, null,
new Node(hash, key, value, null)))
break; // no lock when adding to empty bin
}
//當前正在擴容
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
//鎖住當前陣列i位置上的節點
synchronized (f) {
//判斷是否節點f是否為當前陣列i位置上的節點,防止被其它執行緒修改
if (tabAt(tab, i) == f) {
//當前位置桶的結構為連結串列
if (fh >= 0) {
binCount = 1;
//遍歷連結串列節點
for (Node e = f;; ++binCount) {
K ek;
//若hash值與key值相同,進行替換
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
e.val = value;
break;
}
Node pred = e;
//若連結串列中找不到,尾插節點
if ((e = e.next) == null) {
pred.next = new Node(hash, key,
value, null);
break;
}
}
}
//當前位置桶結構為紅黑樹,TreeBin雜湊值固定為-2
else if (f instanceof TreeBin) {
Node p;
binCount = 2;
//遍歷紅黑樹上節點,更新或增加節點
if ((p = ((TreeBin)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
if (binCount != 0) {
//若連結串列長度超過8,將連結串列轉為紅黑樹
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
//節點數+1,若超過閾值則擴容
addCount(1L, binCount);
return null;
}
/**
* hash演算法
*/
static final int spread(int h) {
return (h ^ (h >>> 16)) & HASH_BITS;
}
複製程式碼
大致流程:
①.首先判斷key和value是否為null,為null拋異常。
與HashMap不同,ConcurrentHashMap不允許null作為key或value,為什麼這樣設計?
因為ConcurrentHashmap是支援併發的,這樣會有一個問題,當你通過get(k)獲取對應的value時,如果獲取到的是null時,你無法判斷,它是put(k,v)的時候value為null,還是這個key從來沒有做過對映。HashMap是非併發的,可以通過contains(key)來做這個判斷。而支援併發的Map在呼叫m.contains(key)和m.get(key),m可能已經不同了。參考
②.重新計算hash值,因為1.8concurrentHashMap引入了紅黑樹來處理較多的雜湊衝突,簡化了hash演算法,不過對比了1.8HashMap的hash演算法,除了因為concurrentHashMap不允許null為key,沒有把null的hash值算為0以外,其多了一步位運算,之所以這樣是為了確保重雜湊算出的一定不為負數,我認為是因為若算出負值,可能會影響後續的節點型別判斷
③.判斷當前table是否為空,空的話初始化table,初始化方法已闡述過不再多提
④.根據重雜湊算出的值通過與運算得到桶索引,利用Unsafe類直接獲取記憶體記憶體中對應位置上的節點,若沒有碰撞即桶中無結點CAS直接新增
⑤.若發生碰撞,判斷桶中第一個節點型別。是ForwardingNode節點的話,表明有其它執行緒正在擴容,則一起進行擴容操作
⑥.剩下場景,按節點相應結構連結串列或紅黑樹的方式插入或更新新節點
⑦.若新增節點後連結串列長度大於8,就把這個連結串列轉換成紅黑樹
⑧.最後節點數量+1,校驗是否超過閾值,若超過則擴容
addCount方法
private final void addCount(long x, int check) {
CounterCell[] as; long b, s;
//利用CAS方法更新baseCount的值
if ((as = counterCells) != null ||
!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
CounterCell a; long v; int m;
boolean uncontended = true;
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
//多執行緒CAS發生失敗的時候執行
fullAddCount(x, uncontended);
return;
}
if (check <= 1)
return;
s = sumCount();
}
///如果check值大於等於0 則需要檢驗是否需要進行擴容操作
if (check >= 0) {
Node[] tab, nt; int n, sc;
while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
(n = tab.length) < MAXIMUM_CAPACITY) {
int rs = resizeStamp(n);
if (sc < 0) {
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0)
break;
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
transfer(tab, nt);
}
else if (U.compareAndSwapInt(this, SIZECTL, sc,
(rs << RESIZE_STAMP_SHIFT) + 2))
transfer(tab, null);
s = sumCount();
}
}
}
複製程式碼
我們可以看到在更新baseCount時用了2次CAS操作,一次直接更新basecount,若更新失敗則更新CELLVALUE,若還更新失敗會呼叫fullAddCount()方法,這個方法會死迴圈一直將由於多執行緒競爭導致CAS失敗的容量變化值存到CounterCell陣列中,為size()方法做準備
size方法
對於ConcurrentHashMap來說,這個table裡到底裝了多少東西其實是個不確定的數量,因為不可能在呼叫size()方法的時候像GC的“stop the world”一樣讓其他執行緒都停下來讓你去統計,因此只能說這個數量是個估計值。
public int size() {
long n = sumCount();
return ((n < 0L) ? 0 :
(n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
(int)n);
}
final long sumCount() {
CounterCell[] as = counterCells; CounterCell a;
long sum = baseCount;
if (as != null) {
for (int i = 0; i < as.length; ++i) {
if ((a = as[i]) != null)
sum += a.value;
}
}
return sum;
}
複製程式碼
為了統計元素個數,ConcurrentHashMap通過累加baseCount和CounterCell陣列中的數量,元素個數儲存baseCount中,部分元素的變化個數儲存在CounterCell陣列中,得到元素的總個數。
transfer方法
支援多執行緒擴容,沒有加鎖 ,其目的不僅為了滿足concurrent的要求,而是希望利用併發處理去減少擴容帶來的時間影響。
以下兩個場景可能會觸發擴容機制(與1.8HashMap相同):
①.當桶中連結串列長度達到閾值8,但整個ConcurrentHashMap節點數量小於64
②.新增節點後,整個ConcurrentHashMap節點數量超過閾值
private final void transfer(Node[] tab, Node[] nextTab) {
int n = tab.length, stride;
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
if (nextTab == null) { // initiating
try {
@SuppressWarnings("unchecked")
// 建立node陣列,容量為當前的兩倍
Node[] nt = (Node[])new Node[n << 1];
nextTab = nt;
} catch (Throwable ex) { // try to cope with OOME
// 若擴容時出現OOM異常,則將閾值設為最大,表明不支援擴容
sizeCtl = Integer.MAX_VALUE;
return;
}
nextTable = nextTab;
transferIndex = n;
}
int nextn = nextTab.length;
// 建立ForwardingNode節點,作為標記位,表明當前位置桶已做過處理
ForwardingNode fwd = new ForwardingNode(nextTab);
boolean advance = true;
boolean finishing = false; // to ensure sweep before committing nextTab
for (int i = 0, bound = 0;;) {
Node f; int fh;
while (advance) {
int nextIndex, nextBound;
if (--i >= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}
//通過CAS設定transferIndex屬性值,並初始化i和bound值
//i指當前處理的槽位序號,bound指需要處理的槽位邊界
//先處理最後一個桶的節點;
else if (U.compareAndSwapInt
(this, TRANSFERINDEX, nextIndex,
nextBound = (nextIndex > stride ?
nextIndex - stride : 0))) {
bound = nextBound;
i = nextIndex - 1;
advance = false;
}
}
// 將原陣列中節點複製到新陣列中去
if (i < 0 || i >= n || i + n >= nextn) {
int sc;
//如果所有的節點都已經完成複製工作 就把nextTable賦值給table 清空臨時物件nextTable
if (finishing) {
nextTable = null;
table = nextTab;
//設定新擴容閾值
sizeCtl = (n << 1) - (n >>> 1);
return;
}
//利用CAS方法更新擴容閾值,在這裡面sizectl值減一,說明新加入一個執行緒參與到擴容操作
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
finishing = advance = true;
i = n; // recheck before commit
}
}
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
else if ((fh = f.hash) == MOVED)
advance = true; // already processed
else {
//鎖住i位置上桶的節點
synchronized (f) {
//確保f是i位置上桶的節點
if (tabAt(tab, i) == f) {
Node ln, hn;
//當前桶是鏈式結構
if (fh >= 0) {
//構造兩個連結串列
int runBit = fh & n;
Node lastRun = f;
//類似於1.8HashMap,只需要看新增的1bit是0還是1進行分類
for (Node p = f.next; p != null; p = p.next) {
//n是就陣列長度,不是長度-1
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
if (runBit == 0) {
ln = lastRun;
hn = null;
}
else {
hn = lastRun;
ln = null;
}
for (Node p = f; p != lastRun; p = p.next) {
int ph = p.hash; K pk = p.key; V pv = p.val;
if ((ph & n) == 0)
ln = new Node(ph, pk, pv, ln);
else
hn = new Node(ph, pk, pv, hn);
}
//在nextTable的i位置上插入一個連結串列
setTabAt(nextTab, i, ln);
//在nextTable的i+n的位置上插入另一個連結串列
setTabAt(nextTab, i + n, hn);
//在table的i位置上插入forwardNode節點 表示已經處理過該節點
setTabAt(tab, i, fwd);
//設定advance為true 返回到上面的while迴圈中 就可以執行i--操作
advance = true;
}
//當前桶是紅黑樹結構,操作和上面的類似
else if (f instanceof TreeBin) {
TreeBin t = (TreeBin)f;
TreeNode lo = null, loTail = null;
TreeNode hi = null, hiTail = null;
int lc = 0, hc = 0;
for (Node e = t.first; e != null; e = e.next) {
int h = e.hash;
TreeNode p = new TreeNode
(h, e.key, e.val, null, null);
if ((h & n) == 0) {
if ((p.prev = loTail) == null)
lo = p;
else
loTail.next = p;
loTail = p;
++lc;
}
else {
if ((p.prev = hiTail) == null)
hi = p;
else
hiTail.next = p;
hiTail = p;
++hc;
}
}
//如果擴容後已經不再需要tree的結構 反向轉換為連結串列結構
ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
(hc != 0) ? new TreeBin(lo) : t;
hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
(lc != 0) ? new TreeBin(hi) : t;
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
setTabAt(tab, i, fwd);
advance = true;
}
}
}
}
}
}
複製程式碼
如圖所示(藍色:hash值第X位為0,灰色:hash值第X位為1)
首次遍歷連結串列分類使用fn&n可以快速把連結串列中的元素區分成兩類只需要看新增的1bit是0還是1,runBit為0,lastRun為節點F,ln為節點F,hn為null
再次遍歷連結串列後,ln鏈:B→A→F;hn鏈:E→D→C(一個正向連結串列,一個反向連結串列)
通過Unsafe類直接操作記憶體把ln連結串列設定到新陣列的i位置,hn連結串列設定到i+n的位置
將原陣列i位置節點改為ForwardingNode節點,表明此桶已做過處理
構造樹節點lo和hi,遍歷紅黑樹中的節點,同樣根據hash&n演算法,把節點分為兩類,分別插入到lo和hi為頭的連結串列中,根據lo和hi連結串列中的元素個數分別生成ln和hn節點,其中ln節點的生成邏輯如下:
(1)如果lo連結串列的元素個數小於等於UNTREEIFY_THRESHOLD,預設為6,則通過untreeify方法把樹節點連結串列轉化成普通節點連結串列;
(2)否則判斷hi連結串列中的元素個數是否等於0:如果等於0,表明重雜湊後原桶中所有節點仍這個桶中,即在lo連結串列中包含了所有原始節點,則設定原始紅黑樹給ln,否則根據lo連結串列重新構造紅黑樹。
看過JDK8 HashMap擴容方法應該會感覺有點像,ConcurrentHashMap對連結串列結構的處理類似HashMap的resize()方法最後部分,對紅黑樹結構處理類似HashMap裡TreeNode內部類的split()方法,TreeBin的構造方法類似於TreeNode內部類的treeify()方法,但是由於ConcurrentHashMap需要保證執行緒安全其操作還是複雜得多
問題:為什麼要反序構建連結串列?
參考了下1.7HashMap頭插節點思想,因為後插入的資料被使用的頻次更高,無法隨機訪問只能從頭開始遍歷查詢,而ConcurrentHashMap利用內建鎖synchronized鎖住桶頭節點,因為後插入的資料被使用的頻次更高,倒序使鎖持有時間更短,等待時間也就短了(僅本人看法)
get方法
給定一個key來確定value的時候,必須滿足兩個條件 key相同 hash值相同,對於節點可能在連結串列或樹上的情況,需要分別去查詢。
public V get(Object key) {
Node[] tab; Node e, p; int n, eh; K ek;
//計算hash值
int h = spread(key.hashCode());
////根據hash值確定節點位置
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
//桶首節點的key與查詢的key相同,則直接返回
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
//樹節點場景
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
//連結串列場景
while ((e = e.next) != null) {
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
複製程式碼
ConcurrentHashMap 1.7與1.8區別
不考慮細節處理,JDK 7中ConcurrentHashMap最主要採用segment,多執行緒競爭會先鎖住segment,在其put操作中會先定位segment位置,再定位segment中具體桶位置,而JDK 8直接操作Node陣列中的桶,鎖住桶首節點,鎖的粒度變小了。另外segment繼承ReentrantLock,而ReentrantLock相對於synchronized關鍵字多了等待可中斷、公平性、繫結多個條件,但針對於效能而言,由於synchronized內建鎖不斷在優化,其效能不會差。