JDK源碼那些事兒之併發ConcurrentHashMap下篇
上一篇文章已經就ConcurrentHashMap進行了部分說明，介紹了其中涉及的常量和變量的含義，有些部分須要結合方法源碼來理解，今天這篇文章就繼續講解併發ConcurrentHashMapjava
前言
本文主要介紹ConcurrentHashMap中的一些重要方法，結合上篇文章中的講解部分進行更進一步的介紹數組
回顧下上篇文章，咱們應該已經知道ConcurrentHashMap的總體結構和HashMap基本一致，不一樣的是處理多線程併發下保證操做的正確性，ConcurrentHashMap經過CAS和synchronized進行併發控制，固然，這種狀況下各類處理都會變的更爲複雜，下面咱們就經過方法來深刻理解ConcurrentHashMap的操做多線程
重要方法
在一些方法中展現了各個變量以及常量的使用，能讓咱們更好的理解其中的操做併發
tabAt/casTabAt/setTabAt
下列方法用於讀寫table數組，使用Unsafe提供的更新獲取volatile變量，CAS更新數組元素等操做dom
// 讀取table[i]
@SuppressWarnings("unchecked")
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);
}
// CAS更新table[i]
static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
Node<K,V> c, Node<K,V> v) {
return U.compareAndSwapObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
}
// 插入table[i]
static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
U.putObjectVolatile(tab, ((long)i << ASHIFT) + ABASE, v);
}
size
size方法返回了一個不精確的值，在多線程環境下，返回一個不精確的值，經過sumCount迭代counterCells統計sum值。ide
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;
}
這裏不少人可能會問，爲何須要疊加counterCells數組的值呢？this
其實這和ConcurrentHashMap特色有關，多線程環境下，同時插入值，執行CAS操做，執行成功的更新了baseCount，而執行失敗的則將值放入到了counterCells數組中，能夠查閱CounterCell內部類源碼，只有一個long類型變量，每次進行插入或者刪除時調用addCount經過CAS操做更新baseCount，失敗時執行fullAddCount方法，初始化counterCells數組，並將1（至關於插入或刪除一個元素）插入到CounterCell類中，這樣儘量保證了Map長度的正確性，這裏理解流程便可，不深刻，addCount部分有具體操做可查看spa
@sun.misc.Contended static final class CounterCell {
volatile long value;
CounterCell(long x) { value = x; }
}
get
參考HashMap，相似操做流程，須要注意的也就是在eh < 0處，若是是特殊節點，好比TreeBin或者ForwardingNode節點，則調用其具體類實現的find方法完成遍歷查詢，內部類解釋能夠參考個人上一篇文章線程
- 計算hash值
- 判斷table是否爲空，不爲空，找到對應hash桶根節點判斷
- 非根節點繼續遍歷樹或者鏈表，存在對應值則返回對應值，不然返回null
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
// 計算key的hash值
int h = spread(key.hashCode());
// table非空而且對應的hash桶根節點不爲空
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
// 查找節點爲根節點
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
// 樹節點或者擴容中（FN節點）
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;
}
// 參考HashMap的hash方法，不一樣之處在於和HASH_BITS進行了一次與操做，最高位變爲了0，即爲正數，由於前一篇文章也已經說過負數hash值有特殊意義
static final int spread(int h) {
return (h ^ (h >>> 16)) & HASH_BITS;
}
containsValue
這裏經過靜態內部類實現Traverser來遍歷數組，具體的內部實現查看上篇文章裏中的內部類說明，advance至關於查找到下一個非空節點rest
public boolean containsValue(Object value) {
if (value == null)
throw new NullPointerException();
Node<K,V>[] t;
if ((t = table) != null) {
Traverser<K,V> it = new Traverser<K,V>(t, t.length, 0, t.length);
for (Node<K,V> p; (p = it.advance()) != null; ) {
V v;
if ((v = p.val) == value || (v != null && value.equals(v)))
return true;
}
}
return false;
}
遍歷時碰見特殊節點的處理上一篇文章中已經畫圖說明，以下：
putVal
putVal總體同HashMap的putVal操做，操做流程上基本相似，只是在多線程操做下須要正確的處理插入值操做，同時若是發現有線程在進行擴容操做時，需幫助擴容，而後再進行插入值的流程操做
final V putVal(K key, V value, boolean onlyIfAbsent) {
// 空值判斷
if (key == null || value == null) throw new NullPointerException();
// hash值計算，保證了hash值爲正數
int hash = spread(key.hashCode());
// 當前bin中元素的個數，判斷是否樹化處理
int binCount = 0;
// 無限循環直到被正確處理
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
// 空表進行初始化操做
if (tab == null || (n = tab.length) == 0)
tab = initTable();
// 計算出的hash桶位置鏈表頭節點無值則經過CAS插入值
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null)))
break; // no lock when adding to empty bin
}
// 若是hash桶鏈表頭節點爲MOVED狀態，即說明有線程在進行擴容操做，則經過helpTransfer幫助擴容操做
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
// hash桶鏈表頭節點加鎖，在多線程環境下其餘線程不能同時操做當前相同的頭節點代碼塊
synchronized (f) {
if (tabAt(tab, i) == f) {
// 正常鏈表插入操做
if (fh >= 0) {
binCount = 1;
for (Node<K,V> e = f;; ++binCount) {
K ek;
// key和hash值相同則進行替換
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
e.val = value;
break;
}
Node<K,V> pred = e;
// 沒匹配到則直接插入到鏈表尾部
if ((e = e.next) == null) {
pred.next = new Node<K,V>(hash, key,
value, null);
break;
}
}
}
// 紅黑樹插入操做
else if (f instanceof TreeBin) {
Node<K,V> p;
binCount = 2;
if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
if (binCount != 0) {
// 達到樹化閾值，則可能進行樹化操做
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
// size+1操做
addCount(1L, binCount);
return null;
}
resizeStamp
前一篇文章在對sizeCtl說明時在多個線程幫忙擴容時其值小於0時作過一些說明，在源碼中涉及到了下面這個方法，先理解清楚這個方法比較重要
這裏的參數每次傳入的都是當前數組的長度，也就是說每次這裏生成的數都與當時擴容時的數組長度有關，Integer.numberOfLeadingZeros(n)，返回二進制表示，前面有多少個連續的0，RESIZE_STAMP_BITS固定爲16，沒發現有提供方法來修改這個變量，位或運算獲得一個值，這個值表示了與擴容時數組的長度相關，這裏需記得是左移了（RESIZE_STAMP_BITS - 1），由於後邊代碼中咱們須要反向操做右移來從新獲取
這裏經過這個方法與數組長度關聯，同時sizeCtl也會與之關聯，同時也記錄當前擴容中的線程數，故sizeCtl在擴容中同時兼顧了兩種做用，一是判斷是不是在同一個批次的擴容中（都是從16擴容到32），同時判斷當前擴容中參與的線程數來肯定是否結束和初始化操做
/**
* Returns the stamp bits for resizing a table of size n.
* Must be negative when shifted left by RESIZE_STAMP_SHIFT.
*/
static final int resizeStamp(int n) {
return Integer.numberOfLeadingZeros(n) | (1 << (RESIZE_STAMP_BITS - 1));
}
addCount
總體來看主要進行了兩部份內容，一是更新baseCount，二是檢查是否進行擴容操做。其實這個方法裏仍是至關複雜的，涉及到了線程私有的僞隨機數生成器ThreadLocalRandom，併發效率更高的LongAdder，不過初學者能夠不用研究那麼深刻，這裏不詳細說明，大概瞭解就好
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)) {
// 更新baseCount失敗
CounterCell a; long v; int m;
boolean uncontended = true;
// 至關於每一個線程的probe就是它在CounterCell數組中的hash code，用來定位counterCells數組
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
// 更新cellvalue失敗則執行fullAddCount，具體不看了，比較複雜，不停嘗試更新計數
// 源碼註釋上也寫了相似LongAdder
fullAddCount(x, uncontended);
return;
}
// 執行到此說明更新計數器成功,判斷是否退出，爲何是1其實仍是有點困惑
if (check <= 1)
return;
s = sumCount();
}
// check大於0表明着對應hash桶下的節點數，檢查是否擴容
// 知足條件幫助擴容，不知足退出
if (check >= 0) {
Node<K,V>[] tab, nt; int n, sc;
// 注意，這裏條件中3個變量賦值同時while判斷
// sc = sizeCtl，tab = table，n = tab.length
// 在併發操做中可能會出現變量錯誤的狀況形成擴容處理出錯，經過resizeStamp保證擴容時版本一致
while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
(n = tab.length) < MAXIMUM_CAPACITY) {
// resizeStamp根據n返回一個擴容版本戳，保證惟一性，上邊一個方法我已經說明了
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;
// 幫助擴容，線程數+1
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();
}
}
}
在上面這段代碼中，不幫助擴容的條件中有些地方讓人困惑
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0)
break;
(sc >>> RESIZE_STAMP_SHIFT) != rs
首先須要明白上邊整個擴容中的第一個線程會經過U.compareAndSwapInt(this, SIZECTL, sc, (rs << RESIZE_STAMP_SHIFT) + 2)設置sizeCtl，以後擴容線程增長則經過U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)更新
sc右移RESIZE_STAMP_SHIFT（因爲RESIZE_STAMP_BITS不提供修改方法，RESIZE_STAMP_SHIFT也只能取到16），第一個條件爲何是這個？須要結合擴容代碼來看，首個線程搶到擴容任務時需先建立nextTable，設置transferIndex，在執行以前須要將sizeCtl更新，即U.compareAndSwapInt(this, SIZECTL, sc,(rs << RESIZE_STAMP_SHIFT) + 2)，代碼存在於addCount和tryPresize方法中，sizeCtl在每次擴容時會更新成(rs << RESIZE_STAMP_SHIFT) + 2。判斷條件裏sc無符號右移，若是是相同的一次擴容過程，則與rs相等是確定的，rs是由resizeStamp根據長度n計算得來，其實最終這裏比較的也就是table的長度，防止屢次擴容下錯誤的幫助了擴容
另外在已經有線程擴容的狀況下增長擴容線程會會更新sizeCtl，U.compareAndSwapInt(this, SIZECTL, sc, sc + 1) 看出在首次更新的基礎上加1便可，擴容線程完成本身的任務同理減1，結合上邊對resizeStamp的說明應該算很清楚了
以上部分也證明了上篇文章中sizeCtl註釋是不正確的
sc == rs + 1 || sc == rs + MAX_RESIZERS
這個條件是有問題的，sc小於0，rs大於0，兩個條件一直爲false，沒有true的可能，從這個條件上看，應該是判斷擴容完畢和擴容線程數達到最大時不能幫助擴容。
咱們想一下，第一次線程擴容時已經將sc更新成(rs << RESIZE_STAMP_SHIFT) + 2，這裏判斷的話須要改成sc == ( rs << RESIZE_STAMP_SHIFT ) +1 纔對，不能將sc右移，右移將會致使低16位記錄的線程數數據丟失，最大線程數判斷同理，應改成sc == ( rs << RESIZE_STAMP_SHIFT ) + MAX_RESIZERS
我在Oracle官網bug庫裏看到已經提到了這個問題：https://bugs.java.com/bugdata...
(nt = nextTable) == null
此時狀態可能代表擴容已經結束或者第一個線程在擴容中，不能幫助擴容
transferIndex <= 0
transfer任務已經被分配完畢，不能分配任務給當前線程，不能幫助擴容，幫助擴容部分下面會說到
helpTransfer
若是正在進行擴容操做，則幫助擴容
/**
* Helps transfer if a resize is in progress.
*/
final Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) {
Node<K,V>[] nextTab; int sc;
// 判斷是否爲ForwardingNode而且nextTable是否已經被建立
if (tab != null && (f instanceof ForwardingNode) &&
(nextTab = ((ForwardingNode<K,V>)f).nextTable) != null) {
// 根據長度獲取擴容戳
int rs = resizeStamp(tab.length);
// 再次驗證是否正在擴容
while (nextTab == nextTable && table == tab &&
(sc = sizeCtl) < 0) {
// 幾個條件上邊已經解釋過了，知足不幫助擴容
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || transferIndex <= 0)
break;
// sizeCtl加1，表示當前線程加入擴容，多了一個線程幫忙
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)) {
transfer(tab, nextTab);
break;
}
}
return nextTab;
}
return table;
}
tryPresize
預先擴容，putAll和treeifyBin中使用到，不知足table容量時，進行一次擴容操做
/**
* Tries to presize table to accommodate the given number of elements.
*
* @param size number of elements (doesn't need to be perfectly accurate)
*/
private final void tryPresize(int size) {
// 判斷長度是否超過最大值，超過則賦值爲最大值，正常則經過tableSizeFor計算擴容後的長度
int c = (size >= (MAXIMUM_CAPACITY >>> 1)) ? MAXIMUM_CAPACITY :
tableSizeFor(size + (size >>> 1) + 1);
int sc;
// 未初始化或擴容完成才能執行本次擴容操做
while ((sc = sizeCtl) >= 0) {
Node<K,V>[] tab = table; int n;
// table未初始化
if (tab == null || (n = tab.length) == 0) {
n = (sc > c) ? sc : c;
// 置爲-1表示數組初始化，前一篇文章已經說明
if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
if (table == tab) {
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = nt;
sc = n - (n >>> 2);
}
} finally {
// 此時至關於閾值
sizeCtl = sc;
}
}
}
// 已經初始化，擴容長度小於閾值或者大於最大值，不進行擴容操做
else if (c <= sc || n >= MAXIMUM_CAPACITY)
break;
// 再次驗證table未改變
else if (tab == table) {
int rs = resizeStamp(n);
// 同上邊代碼部分，判斷是否幫助擴容
if (sc < 0) {
Node<K,V>[] nt;
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);
}
}
}
transfer
table遷移操做,經過transferIndex來完成任務的分配，以前文章變量中也說起了MIN_TRANSFER_STRIDE（最小步長），對每一個擴容線程申請遷移的hash桶數量作了限制，每次須要擴容線程執行完畢已經領取完的hash桶遷移任務才能夠繼續領取任務幫助遷移，最後一個遷移線程在遷移完畢後會進行檢查
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
int n = tab.length, stride;
// 設置步長，即每一個遷移任務遷移多少個hash桶，默認最小遷移步長16
// 即每一個擴容線程最小遷移16個hash桶
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
// nextTab未初始化，則進行初始化操做，這裏不須要CAS，調用的地方已經作了控制，保證只有一個線程能執行
if (nextTab == null) { // initiating
try {
@SuppressWarnings("unchecked")
// 新數組長度擴容爲原有數組的2倍
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // try to cope with OOME
// 內存溢出時不能繼續擴容
sizeCtl = Integer.MAX_VALUE;
return;
}
nextTable = nextTab;
transferIndex = n;
}
int nextn = nextTab.length;
// 設置ForwardingNode節點
ForwardingNode<K,V> fwd = new ForwardingNode<K,V>(nextTab);
// 線程能夠繼續分配遷移任務的標識
boolean advance = true;
// 設置結束標識
boolean finishing = false; // to ensure sweep before committing nextTab
// i表示數組下標，bound表示遷移任務的最小下標
for (int i = 0, bound = 0;;) {
Node<K,V> f; int fh;
// advance爲false則代表當前線程分配的遷移任務未完成或已經擴容完畢
while (advance) {
int nextIndex, nextBound;
// --i 大於等於 bound 則代表本次分配的遷移任務還未完成，將advance置爲false
// 代表不能繼續分配遷移任務
if (--i >= bound || finishing)
advance = false;
// 設置nextIndex
// 若是小於等於0則表示遷移hash桶已被分配完畢，不用繼續，將advance置爲false
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}
// 設置遷移任務區間bound到i
else if (U.compareAndSwapInt
(this, TRANSFERINDEX, nextIndex,
nextBound = (nextIndex > stride ?
nextIndex - stride : 0))) {
bound = nextBound;
i = nextIndex - 1;
advance = false;
}
}
// 上邊計算了區間和任務狀態
// i < 0 上邊代碼已經說明，transfer任務已經執行完畢，退出
// i >= n 這裏n表示的是傳入的tab數組長度，而i有可能由於transferIndex改變而改變
// 好比連續擴容從16擴容到32，而後又從32擴容到64，此時這個條件是可能成立的，這裏的i有可能在32到64之間，大於n的32
// 不在一個擴容維度內，需退出。最後一個條件沒看明白是什麼狀況出現這種狀態
if (i < 0 || i >= n || i + n >= nextn) {
int sc;
if (finishing) {
// 擴容遷移完畢設置table和sizeCtl
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
// 線程數減1，代表當前線程退出
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
// 判斷當前線程是否爲最後一個擴容線程，不是，則退出，條件能夠看上邊的說明，已經講解過
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
// 肯定當前線程爲最後一個擴容線程，則須要進行檢查工做
// 檢查全部的舊數組hash桶是否被正確的遷移
finishing = advance = true;
i = n; // recheck before commit
}
}
// i處的hash桶爲null則直接放置ForwardingNode節點
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
// i處的hash桶爲ForwardingNode節點
else if ((fh = f.hash) == MOVED)
// 最後的線程執行檢查
advance = true; // already processed
else {
synchronized (f) {
// 再次驗證hash桶頭節點爲f
if (tabAt(tab, i) == f) {
// 進行遷移任務,相似HashMap，分高位和低位，不明白的能夠看我HashMap的文章
Node<K,V> ln, hn;
if (fh >= 0) {
// 正常鏈表操做
// runBit代表首節點的位置，0則表示在低位，非0表示在高位
int runBit = fh & n;
Node<K,V> lastRun = f;
// 找到尾部最後一個高低位不一樣的節點，以後的節點不須要進行操做，直接進行復用
for (Node<K,V> p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
// 低位lastRun在下面循環時使用
if (runBit == 0) {
ln = lastRun;
hn = null;
}
// 高位lastRun在下面循環時使用
else {
hn = lastRun;
ln = null;
}
// 肯定lastRun爲了提升效率，複用原有鏈表
for (Node<K,V> 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<K,V>(ph, pk, pv, ln);
// 高位鏈表
else
hn = new Node<K,V>(ph, pk, pv, hn);
}
// 新數組上設置低位鏈表
setTabAt(nextTab, i, ln);
// 新數組上設置高位鏈表
setTabAt(nextTab, i + n, hn);
// 舊數組i處設置爲ForwardingNode節點
setTabAt(tab, i, fwd);
advance = true;
}
// 紅黑樹經過TreeBin操做
else if (f instanceof TreeBin) {
TreeBin<K,V> t = (TreeBin<K,V>)f;
// 一樣劃分爲高低位進行處理，經過鏈表來操做
TreeNode<K,V> lo = null, loTail = null;
TreeNode<K,V> hi = null, hiTail = null;
int lc = 0, hc = 0;
for (Node<K,V> e = t.first; e != null; e = e.next) {
int h = e.hash;
TreeNode<K,V> p = new TreeNode<K,V>
(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;
}
}
// 同鏈表相似，判斷下是否需轉成鏈表，經過TreeBin將高低位鏈表構建成紅黑樹
ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
(hc != 0) ? new TreeBin<K,V>(lo) : t;
hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
(lc != 0) ? new TreeBin<K,V>(hi) : t;
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
setTabAt(tab, i, fwd);
advance = true;
}
}
}
}
}
}
遷移任務是從數組尾部向頭部進行，這樣作的目的應該是與迭代正向操做相反來減小衝突，當迭代時是已經遷移好的hash桶，遷移時是已經迭代完畢的hash桶
clear
清空操做，比較簡單
public void clear() {
// 刪除節點數記錄最後須要更新
long delta = 0L; // negative number of deletions
// 數組下標
int i = 0;
Node<K,V>[] tab = table;
while (tab != null && i < tab.length) {
int fh;
Node<K,V> f = tabAt(tab, i);
// hash桶首節點爲null代表不須要執行
if (f == null)
++i;
// 擴容中幫助擴容而後從新開始循環清空操做
else if ((fh = f.hash) == MOVED) {
tab = helpTransfer(tab, f);
i = 0; // restart
}
// 正常鏈表或TreeBin節點
else {
synchronized (f) {
if (tabAt(tab, i) == f) {
Node<K,V> p = (fh >= 0 ? f :
(f instanceof TreeBin) ?
((TreeBin<K,V>)f).first : null);
// 獲取hash桶的節點數
while (p != null) {
--delta;
p = p.next;
}
// 將hash桶置null
setTabAt(tab, i++, null);
}
}
}
}
// 更新數組長度
if (delta != 0L)
addCount(delta, -1);
}
總結
本文緊接上一篇文章講解了ConcurrentHashMap的重要的方法，對於一些變量和常量結合方法進行了更多的解釋說明，自己而言仍是比較複雜，其中部分筆者也不能徹底理解，不過總體的流程有了一個更清晰的認知，重點須要理解的在下面幾點：
- 涉及到Map長度的計算：經過counterCells完成以及經過addCount進行長度的更新
- 擴容操做：sizeCtl的設置以及更新和各類狀況下對應的含義
- 遷移操做：遷移步長，線程檢查
- 節點類型：幾種節點類型的不一樣處理方式
固然，有些條件可能比較複雜，難以理解，只能盡力多看多想，但願對各位有所幫助
以上內容若有問題歡迎指出，筆者驗證後將及時修正，謝謝
相關文章
- 1. JDK源碼那些事兒之併發ConcurrentHashMap上篇
- 2. JDK源碼那些事兒之紅黑樹基礎下篇
- 3. JDK源碼那些事兒之淺析Thread下篇
- 4. JDK源碼那些事兒之SynchronousQueue下篇
- 5. JDK源碼那些事兒之神祕的ThreadLocal下篇
- 6. JDK源碼那些事兒之HashMap.TreeNode
- 7. JDK源碼那些事兒之LinkedBlockingDeque
- 8. JDK源碼那些事兒之LockSupport
- 9. JDK源碼那些事兒之ConcurrentLinkedDeque
- 10. JDK源碼那些事兒之PriorityBlockingQueue
- 更多相關文章...
- • Rust 併發編程 - RUST 教程
- • Docker 資源彙總 - Docker教程
- • 再有人問你分佈式事務，把這篇扔給他
- • 互聯網組織的未來：剖析GitHub員工的任性之源
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. JDK源碼那些事兒之併發ConcurrentHashMap上篇
- 2. JDK源碼那些事兒之紅黑樹基礎下篇
- 3. JDK源碼那些事兒之淺析Thread下篇
- 4. JDK源碼那些事兒之SynchronousQueue下篇
- 5. JDK源碼那些事兒之神祕的ThreadLocal下篇
- 6. JDK源碼那些事兒之HashMap.TreeNode
- 7. JDK源碼那些事兒之LinkedBlockingDeque
- 8. JDK源碼那些事兒之LockSupport
- 9. JDK源碼那些事兒之ConcurrentLinkedDeque
- 10. JDK源碼那些事兒之PriorityBlockingQueue