//下一个哈希表
private transient volatile Node<K,V>[] nextTable;
//计数的基准值
private transient volatile long baseCount;
//控制变量,不同场景有不同用途,参考下文
private transient volatile int sizeCtl;
//并发搬运过程中CAS获取区段的下限值
private transient volatile int transferIndex;
//计数cell初始化或者扩容时基于此字段使用自旋锁
private transient volatile int cellsBusy;
//加速多核CPU计数的cell数组
private transient volatile CounterCell[] counterCells;
四、安全操作Node<K,V>数组
=====================
static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
return (Node<K,V>)U.getReferenceAcquire(tab, ((long)i << ASHIFT) + ABASE);
}static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
Node<K,V> c, Node<K,V> v) {
return U.compareAndSetReference(tab, ((long)i << ASHIFT) + ABASE, c, v);
}static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
U.putReferenceRelease(tab, ((long)i << ASHIFT) + ABASE, v);
}
对Node<K,V>[] 上任意一个index的读取和写入都使用了Unsafe辅助类,table本身是volatile类型的并不能保证其下的每个元素的内存语义也是volatile类型;
需要借助于Unsafe来保证Node<K,V>[]元素的“读/写/CAS”操作在多核并发环境下的原子或者可见性。
五、读操作get为什么是线程安全的
=====================
首先需要明确的是,C13Map的读操作一般是不加锁的(TreeBin的读解锁除外),而读操作与写操作有可能并行;可以保证的是,因为C13Map的写操作都要获取bin头部的syncronized互斥锁,能保证最多只有一个线程在做更新,这其实是一个单线程写、多线程读的并发安全性的问题。
C13Map的get方法
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
//执行扰动函数
int h = spread(key.hashCode());
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;
}
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;
}
1、如果当前哈希表table为null
=======================
哈希表未初始化或者正在初始化未完成,直接返回null;虽然line5和line18之间其它线程可能经历了千山万水,至少在判断tab==null的时间点key肯定是不存在的,返回null符合某一时刻的客观事实。
2、如果读取的bin头节点为null
======================
说明该槽位尚未有节点,直接返回null。
3、如果读取的bin是一个链表
===================
说明头节点是个普通Node。
(1)如果正在发生链表向红黑树的treeify工作,因为treeify本身并不破坏旧的链表bin的结构,只是在全部treeify完成后将头节点一次性替换为新创建的TreeBin,可以放心读取。
(2)如果正在发生resize且当前bin正在被transfer,因为transfer本身并不破坏旧的链表bin的结构,只是在全部transfer完成后将头节点一次性替换为ForwardingNode,可以放心读取。
(3)如果其它线程正在操作链表,在当前线程遍历链表的任意一个时间点,都有可能同时在发生add/replace/remove操作。
-
如果是add操作,因为链表的节点新增从JDK8以后都采用了后入式,无非是多遍历或者少遍历一个tailNode。
-
如果是remove操作,存在遍历到某个Node时,正好有其它线程将其remove,导致其孤立于整个链表之外;但因为其next引用未发生变更,整个链表并没有断开,还是可以照常遍历链表直到tailNode。
-
如果是replace操作,链表的结构未变,只是某个Node的value发生了变化,没有安全问题。
结论:对于链表这种线性数据结构,单线程写且插入操作保证是后入式的前提下,并发读取是安全的;不会存在误读、链表断开导致的漏读、读到环状链表等问题。
4、如果读取的bin是一个红黑树
====================
说明头节点是个TreeBin节点。
(1)如果正在发生红黑树向链表的untreeify操作,因为untreeify本身并不破坏旧的红黑树结构,只是在全部untreeify完成后将头节点一次性替换为新创建的普通Node,可以放心读取。
(2)如果正在发生resize且当前bin正在被transfer,因为transfer本身并不破坏旧的红黑树结构,只是在全部transfer完成后将头节点一次性替换为ForwardingNode,可以放心读取。
(3)如果其他线程在操作红黑树,在当前线程遍历红黑树的任意一个时间点,都可能有单个的其它线程发生add/replace/remove/红黑树的翻转等操作,参考下面的红黑树的读写锁实现。
TreeBin中的读写锁实现
TreeNode<K,V> root;
volatile TreeNode<K,V> 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
private final void lockRoot() { //如果一次性获取写锁失败,进入contendedLock循环体,循环获取写锁或者休眠等待
if (!U.compareAndSetInt(this, LOCKSTATE, 0, WRITER))
contendedLock(); // offload to separate method
} private final void unlockRoot() { lockState = 0;
} //对红黑树加互斥锁,也就是写锁
private final void contendedLock() { boolean waiting = false;
for (int s;😉 {
//如果lockState除了第二位外其它位上都为0,表示红黑树当前既没有上读锁,又没有上写锁,仅有可能存在waiter,可以尝试直接获取写锁
if (((s = lockState) & ~WAITER) == 0) {
if (U.compareAndSetInt(this, LOCKSTATE, s, WRITER)) {
if (waiting)
waiter = null;
return;
} } //如果lockState第二位是0,表示当前没有线程在等待写锁
else if ((s & WAITER) == 0) {
//将lockState的第二位设置为1,相当于打上了waiter的标记,表示有线程在等待写锁
if (U.compareAndSetInt(this, LOCKSTATE, s, s | WAITER)) {
waiting = true;
waiter = Thread.currentThread(); } } //休眠当前线程
else if (waiting)
LockSupport.park(this);
} } //查找红黑树中的某个节点
final Node<K,V> find(int h, Object k) { if (k != null) {
for (Node<K,V> e = first; e != null; ) {
int s; K ek; //如果当前有waiter或者有写锁,走线性检索,因为红黑树虽然替代了链表,但其内部依然保留了链表的结构,虽然链表的查询性能一般,但根据先前的分析其读取的安全性有保证。
//发现有写锁改走线性检索,是为了避免等待写锁释放花去太久时间; 而发现有waiter改走线性检索,是为了避免读锁叠加的太多,导致写锁线程需要等待太长的时间; 本质上都是为了减少读写碰撞
//线性遍历的过程中,每遍历到下一个节点都做一次判断,一旦发现锁竞争的可能性减少就改走tree检索以提高性能
if (((s = lockState) & (WAITER|WRITER)) != 0) {
if (e.hash == h &&
((ek = e.key) == k || (ek != null && k.equals(ek))))
return e;
e = e.next; } //对红黑树加共享锁,也就是读锁,CAS一次性增加4,也就是增加的只是3~32位
else if (U.compareAndSetInt(this, LOCKSTATE, s,
s + READER)) { TreeNode<K,V> r, p; try {
p = ((r = root) == null ? null :
r.findTreeNode(h, k, null));
} finally {
Thread w; //释放读锁,如果释放完毕且有waiter,则将其唤醒
if (U.getAndAddInt(this, LOCKSTATE, -READER) ==
(READER|WAITER) && (w = waiter) != null)
LockSupport.unpark(w); } return p;
} } } return null;
} //更新红黑树中的某个节点
final TreeNode<K,V> putTreeVal(int h, K k, V v) { Class<?> kc = null;
boolean searched = false;
for (TreeNode<K,V> p = root;😉 {
int dir, ph; K pk; //…省略处理红黑树数据结构的代码若干
else {
//写操作前加互斥锁
lockRoot(); try {
root = balanceInsertion(root, x); } finally {
//释放互斥锁
unlockRoot(); } } break;
} } assert checkInvariants(root); return null;
}}
红黑树内置了一套读写锁的逻辑,其内部定义了32位的int型变量lockState,第1位是写锁标志位,第2位是写锁等待标志位,从3~32位则是共享锁标志位。
读写操作是互斥的,允许多个线程同时读取,但不允许读写操作并行,同一时刻只允许一个线程进行写操作;这样任意时间点读取的都是一个合法的红黑树,整体上是安全的。
有的同学会产生疑惑,写锁释放时为何没有将waiter唤醒的操作呢?是否有可能A线程进入了等待区,B线程获取了写锁,释放写锁时仅做了lockState=0的操作。
那么A线程是否就没有机会被唤醒了,只有等待下一个读锁释放时的唤醒了呢 ?
显然这种情况违背常理,C13Map不会出现这样的疏漏,在进一步观察,红黑树的变更操作的范围,也就是在putValue/replaceNode那一层,都是对BIN的头节点加了synchornized互斥锁的,同一时刻只能有一个写线程进入TreeBin的方法范围内,当写线程发现当前waiter不为空,其实此waiter只能是当前线程自己,可以放心的获取解锁,不用担心无法被唤醒的问题。
TreeBin在find读操作检索时,在linearSearch(线性检索)和treeSearch(树检索)间做了折衷,前者性能差但并发安全,后者性能佳但要做并发控制,可能导致锁竞争;设计者使用线性检索来尽量避免读写碰撞导致的锁竞争,但评估到race condition已消失时,又立即趋向于改用树检索来提高性能,在安全和性能之间做到了极佳的平衡。具体的折衷策略请参考find方法及注释。
由于有线性检索这样一个抄底方案,以及入口处bin头节点的synchornized机制,保证了进入到TreeBin整体代码块的写线程只有一个;TreeBin中读写锁的整体设计与ReentrantReadWriteLock相比还是简单了不少,比如并未定义用于存放待唤醒线程的threadQueue,以及读线程仅会自旋而不会阻塞等等, 可以看做是特定条件下ReadWriteLock的简化版本。
5、如果读取的bin是一个ForwardingNode
===============================
说明当前bin已迁移,调用其find方法到nextTable读取数据。
forwardingNode的find方法
static final class ForwardingNode<K,V> extends Node<K,V> {
final Node<K,V>[] nextTable;
ForwardingNode(Node<K,V>[] tab) {
super(MOVED, null, null);
this.nextTable = tab;
}
//递归检索哈希表链
Node<K,V> find(int h, Object k) {
// loop to avoid arbitrarily deep recursion on forwarding nodes
outer: for (Node<K,V>[] tab = nextTable;😉 {
Node<K,V> e; int n;
if (k == null || tab == null || (n = tab.length) == 0 ||
(e = tabAt(tab, (n - 1) & h)) == null)
return null;
for (;😉 {
int eh; K ek;
if ((eh = e.hash) == h &&
((ek = e.key) == k || (ek != null && k.equals(ek))))
return e;
if (eh < 0) {
if (e instanceof ForwardingNode) {
tab = ((ForwardingNode<K,V>)e).nextTable;
continue outer;
}
else
return e.find(h, k);
}
if ((e = e.next) == null)
return null;
}
}
}
}
ForwardingNode中保存了nextTable的引用,会转向下一个哈希表进行检索,但并不能保证nextTable就一定是currentTable,因为在高并发插入的情况下,极短时间内就可以导致哈希表的多次扩容,内存中极有可能驻留一条哈希表链,彼此与bin的头节点上的ForwardingNode相连,线程刚读取时拿到的是table1,遍历时却有可能经历了哈希表的链条。
eh<0有三种情况:
-
如果是ForwardingNode继续遍历下一个哈希表。
-
如果是TreeBin,调用其find方法进入TreeBin读写锁的保护区读取数据。
-
如果是ReserveNode,说明当前有compute计算中,整条bin还是一个空结构,直接返回null。
6、如果读取的bin是一个ReserveNode
============================
ReserveNode用于compute/computeIfAbsent原子计算的方法,在BIN的头节点为null且计算尚未完成时,先在bin的头节点打上一个ReserveNode的占位标记。
读操作发现ReserveNode直接返回null,写操作会因为争夺ReserveNode的互斥锁而进入阻塞态,在compute完成后被唤醒后循环重试。
六、写操作putValue/replaceNode为什么是线程安全的
======================================
典型的编程范式如下:
C13Map的putValue方法
Node<K,V>[] tab = table; //将堆中的table变量赋给线程堆栈中的局部变量
Node f = tabAt(tab, i );if(f==null){
//当前槽位没有头节点,直接CAS写入
if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))
break;
}else if(f.hash == MOVED){
//加入协助搬运行列
helpTransfer(tab,f);}//不是forwardingNode
else if(f.hash != MOVED){
//先锁住I槽位上的头节点
synchronized (f) {
//再doubleCheck看此槽位上的头节点是否还是f
if (tabAt(tab, i) == f) {
…各种写操作
}
}
}
1、当前槽位如果头节点为null时,直接CAS写入
=============================
有人也许会质疑,如果写入时resize操作已完成,发生了table向nextTable的转变,是否会存在写入的是旧表的bin导致数据丢失的可能 ?
这种可能性是不存在的,因为一个table在resize完成后所有的BIN都会被打上ForwardingNode的标记,可以形象的理解为所有槽位上都插满了红旗,而此处在CAS时的compare的变量null,能够保证至少在CAS原子操作发生的时间点table并未发生变更。
2、当前槽位如果头节点不为null
=====================
这里采用了一个小技巧:先锁住I槽位上的头节点,进入同步代码块后,再doubleCheck看此槽位上的头节点是否有变化。
进入同步块后还需要doubleCheck的原因:虽然一开始获取到的头节点f并非ForwardingNode,但在获取到f的同步锁之前,可能有其它线程提前获取了f的同步锁并完成了transfer工作,并将I槽位上的头节点标记为ForwardingNode,此时的f就成了一个过时的bin的头节点。
然而因为标记操作与transfer作为一个整体在同步的代码块中执行,如果doubleCheck的结果是此槽位上的头节点还是f,则表明至少在当前时间点该槽位还没有被transfer到新表(假如当前有transfer in progress的话),可以放心的对该bin进行put/remove/replace等写操作。
只要未发生transfer或者treeify操作,链表的新增操作都是采取后入式,头节点一旦确定不会轻易改变,这种后入式的更新方式保证了锁定头节点就等于锁住了整个bin。
如果不作doubleCheck判断,则有可能当前槽位已被transfer,写入的还是旧表的BIN,从而导致写入数据的丢失;也有可能在获取到f的同步锁之前,其它线程对该BIN做了treeify操作,并将头节点替换成了TreeBin, 导致写入的是旧的链表,而非新的红黑树;
3、doubleCheck是否有ABA问题
=========================
也许有人会质疑,如果有其它线程提前对当前bin进行了的remove/put的操作,引入了新的头节点,并且恰好发生了JVM的内存释放和重新分配,导致新的Node的引用地址恰好跟旧的相同,也就是存在所谓的ABA问题。
这个可以通过反证法来推翻,在带有GC机制的语言环境下通常不会发生ABA问题,因为当前线程包含了对头节点f的引用,当前线程并未消亡,不可能存在f节点的内存被GC回收的可能性。
还有人会质疑,如果在写入过程中主哈希表发生了变化,是否可能写入的是旧表的bin导致数据丢失,这个也可以通过反证法来推翻,因为table向nextTable的转化(也就是将resize后的新哈希表正式commit)只有在所有的槽位都已经transfer成功后才会进行,只要有一个bin未transfer成功,则说明当前的table未发生变化,在当前的时间点可以放心的向table的bin内写入数据。
4、如何操作才安全
=============
可以总结出规律,在对table的槽位成功进行了CAS操作且compare值为null,或者对槽位的非forwardingNode的头节点加锁后,doubleCheck头节点未发生变化,对bin的写操作都是安全的。
七、原子计算相关方法
==============
原子计算主要包括:computeIfAbsent、computeIfPresent、compute、merge四个方法。
1、几个方法的比较
=============
主要区别如下:
(1)computeIfAbsent只会在判断到key不存在时才会插入,判空与插入是一个原子操作,提供的FunctionalInterface是一个二元的Function, 接受key参数,返回value结果;如果计算结果为null则不做插入。
(2)computeIfPresent只会在判读单到Key非空时才会做更新,判断非空与插入是一个原子操作,提供的FunctionalInterface是一个三元的BiFunction,接受key,value两个参数,返回新的value结果;如果新的value为null则删除key对应节点。
(3)compute则不加key是否存在的限制,提供的FunctionalInterface是一个三元的BiFunction,接受key,value两个参数,返回新的value结果;如果旧的value不存在则以null替代进行计算;如果新的value为null则保证key对应节点不会存在。
(4)merge不加key是否存在的限制,提供的FunctionalInterface是一个三元的BiFunction,接受oldValue, newVALUE两个参数,返回merge后的value;如果旧的value不存在,直接以newVALUE作为最终结果,存在则返回merge后的结果;如果最终结果为null,则保证key对应节点不会存在。
2、何时会使用ReserveNode占位
========================
如果目标bin的头节点为null,需要写入的话有两种手段:一种是生成好新的节点r后使用casTabAt(tab, i, null, r)原子操作,因为compare的值为null可以保证并发的安全;
另外一种方式是创建一个占位的ReserveNode,锁住该节点并将其CAS设置到bin的头节点,再进行进一步的原子计算操作;这两种办法都有可能在CAS的时候失败,需要自己反复尝试。
(1)为什么只有computeIfAbsent/compute方法使用占位符的方式
=============================================
computeIfPresent只有在BIN结构非空的情况下才会展开原子计算,自然不存在需要ReserveNode占位的情况;锁住已有的头节点即可。
computeIfAbsent/compute方法在BIN结构为空时,需要展开Function或者BiFunction的运算,这个操作是外部引入的需要耗时多久无法准确评估;这种情况下如果采用先计算,再casTabAt(tab, i, null, r)的方式,如果有其它线程提前更新了这个BIN,那么就需要重新锁定新加入的头节点,并重复一次原子计算(C13Map无法帮你缓存上次计算的结果,因为计算的入参有可能会变化),这个开销是比较大的。
而使用ReserveNode占位的方式无需等到原子计算出结果,可以第一时间先抢占BIN的所有权,使其他并发的写线程阻塞。
(2)merge方法为何不需要占位
=====================
原因是如果BIN结构为空时,根据merge的处理策略,老的value为空则直接使用新的value替代,这样就省去了BiFunction中新老value进行merge的计算,这个消耗几乎是没有的;因此可以使用casTabAt(tab, i, null, r)的方式直接修改,避免了使用ReserveNode占位,锁定该占位ReserveNode后再进行CAS修改的两次CAS无谓的开销。
C13Map的compute方法
public V compute(K key,
BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
if (key == null || remappingFunction == null)
throw new nullPointerException();
int h = spread(key.hashCode());
V val = null;
int delta = 0;
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();
else if ((f = tabAt(tab, i = (n - 1) & h)) == null) {
//创建占位Node
Node<K, V> r = new ReservationNode<K, V>();
//先锁定该占位Node
synchronized ® {
//将其设置到BIN的头节点
if (casTabAt(tab, i, null, r)) {
binCount = 1;
Node<K, V> node = null;
try {
//开始原子计算
if ((val = remappingFunction.apply(key, null)) != null) {
delta = 1;
node = new Node<K, V>(h, key, val, null);
}
} finally {
//设置计算后的最终节点
setTabAt(tab, i, node);
}
}
}
if (binCount != 0)
break;
} else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
synchronized (f) {
if (tabAt(tab, i) == f) {
if (fh >= 0) {
//此处省略对普通链表的变更操作
} else if (f instanceof TreeBin) {
//此处省略对红黑树的变更操作
}
}
}
}
}
if (delta != 0)
addCount((long) delta, binCount);
return val;
}
3、如何保证原子性
=============
computeIfAbsent/computeIfPresent中判空与计算是原子操作,根据上述分析主要是通过casTabAt(tab, i, null, r)原子操作,或者使用ReserveNode占位并锁定的方式,或者锁住bin的头节点的方式来实现的。
也就是说整个bin一直处于锁定状态,在获取到目标KEY的value是否为空以后,其它线程无法变更目标KEY的值,判空与计算自然是原子的。
而casTabAt(tab, i, null, r)是由硬件层面的原子指令来保证的,能够保证同一个内存区域在compare和set操作之间不会有任何其它指令对其进行变更。
八、resize过程中的并发transfer
==========================
C13Map中总共有三处地方会触发transfer方法的调用,分别是addCount、tryPresize、helpTransfer三个函数。
-
addCount 用于写操作完成后检验元素数量,如果超过了sizeCtl中的阈值,则触发resize扩容和旧表向新表的transfer。
-
tryPresize 是putAll一次性插入一个集合前的自检,如果集合数目较大,则预先触发一次resize扩容和旧表向新表的transfer。
-
helpTransfer 是写操作过程中发现bin的头节点是ForwardingNode, 则调用helpTransfer加入协助搬运的行列。
1、开始transfer前的检查工作
======================
以addCount中的检查逻辑为例:
addCount中的transfer检查
Node<K, V>[] tab, nt;
int n, sc;
//当前的tableSize已经超过sizeCtl阈值,且小于最大值
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))
//尚未搬运,当前线程是本次resize工作的第一个线程,设置初始值为2,非常巧妙的设计
transfer(tab, null);
s = sumCount();
}
多处应用了对变量sizeCtl的CAS操作,sizeCtl是一个全局控制变量。
参考下此变量的定义:private transient volatile int sizeCtl;
-
初始值是0表示哈希表尚未初始化
-
如果是-1表示正在初始化,只允许一个线程进入初始化代码块
-
初始化或者reSize成功后,sizeCtl=loadFactor * tableSize也就是触发再次扩容的阈值,是一个正整数
-
在扩容过程中,sizeCtrl是一个负整数,其高16位是与当前的tableSize关联的邮戳resizeStamp,其低16位是当前从事搬运工作的线程数加1
在方法的循环体中每次都将table、sizeCtrl、nextTable赋给局部变量以保证读到的是当前的最新值,且保证逻辑计算过程中变量的稳定。
如果sizeCtrl中高16位的邮戳与当前tableSize不匹配,或者搬运线程数达到了最大值,或者所有搬运的线程都已经退出(只有在遍历完所有槽位后才会退出,否则会一直循环),或者nextTable已经被清空,跳过搬运操作。
如果满足搬运条件,则对sizeCtrl做CAS操作,sizeCtrl>=0时设置初始线程数为2,sizeCtrl<0时将其值加1,CAS成功后开始搬运操作,失败则进入下一次循环重新判断。
首个线程设置初始值为2的原因是:线程退出时会通过CAS操作将参与搬运的总线程数-1,如果初始值按照常规做法设置成1,那么减1后就会变为0。
此时其它线程发现线程数为0时,无法区分是没有任何线程做过搬运,还是有线程做完搬运但都退出了,也就无法判断要不要加入搬运的行列。
值得注意的是,代码中的“sc == rs + 1 || sc == rs + MAX_RESIZERS“是JDK8中的明显的BUG,少了rs无符号左移16位的操作;JDK12已经修复了此问题。
2、并发搬运过程和退出机制
=================
C13Map的transfer方法
private final void transfer(Node<K, V>[] tab, Node<K, V>[] nextTab) {
int n = tab.length, stride;
//一次搬运多少个槽位
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE;
if (nextTab == null) {
try {
//首个搬运线程,负责初始化nextTable
Node<K, V>[] nt = (Node<K, V>[]) new Node<?, ?>[n << 1];
nextTab = nt;
} catch (Throwable ex) {
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; // 保证提交nextTable之前已遍历旧表的所有槽位
for (int i = 0, bound = 0; ; ) {
Node<K, V> f;
int fh;
//循环CAS获取下一个搬运区段
while (advance) {
int nextIndex, nextBound;
//搬运已结束,或者当前区段尚未完成,退出循环体;最后一次抄底扫描时,仅辅助做i减一的运算
if (–i >= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
} 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;
if (finishing) {
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
//并非最后一个退出的线程
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
finishing = advance = true;
//异常巧妙的设计,最后一个线程推出前将i回退到最高位,等于是强制做最后一次的全表扫描;程序直接执行后续的else if代码,看有没有哪个槽位漏掉了,或者说是否全部是forwardingNode标记;
//可以视为抄底逻辑,虽然检测到漏掉槽位的概率基本是0
i = n;
}
} else if ((f = tabAt(tab, i)) == null)
//空槽位直接打上forwardingNode标记,CAS失败下一次循环继续搬运该槽位,成功则进入下一个槽位
advance = casTabAt(tab, i, null, fwd);
else if ((fh = f.hash) == MOVED)
advance = true; //最后一次抄底遍历时,正常情况下所有的槽位应该都被打上forwardingNode标记
else {
//锁定头节点
synchronized (f) {
if (tabAt(tab, i) == f) {
Node<K, V> ln, hn;
if (fh >= 0) {
//…此处省略链表搬运代码:职责是将链表拆成两份,搬运到nextTable的i和i+n槽位
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
//设置旧表对应槽位的头节点为forwardingNode
setTabAt(tab, i, fwd);
advance = true;
} else if (f instanceof TreeBin) {
//…此处省略红黑树搬运代码:职责是将红黑树拆成两份,搬运到nextTable的i和i+n槽位,如果满足红黑树的退化条件,顺便将其退化为链表
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
//设置旧表对应槽位的头节点为forwardingNode
setTabAt(tab, i, fwd);
advance = true;
}
}
}
}
}
}
多个线程并发搬运时,如果是首个搬运线程,负责nextTable的初始化工作;然后借助于全局的transferIndex变量从当前table的n-1槽位开始依次向低位扫描搬运,通过对transferIndex的CAS操作一次获取一个区段(默认是16),当transferIndex达到最低位时,不再能够获取到新的区段,线程开始退出,退出时会在sizeCtl上将总的线程数减一,最后一个退出的线程将扫描坐标i回退到最高位,强迫做一次抄底的全局扫描。
3、transfer过程中的读写安全性分析
=========================
(1)首先是transfer过程中是否有可能全局的哈希表table发生多次resize,或者说存在过期的风险?
===========================================================
观察nextTable提交到table的代码,发现只有在所有线程均搬运完毕退出后才会commit,所以但凡有一个线程在transfer代码块中,table都不可能被替换;所以不存在table过期的风险。
(2)有并发的写操作时,是否存在安全风险?
=========================
因为transfer操作与写操作都要竞争bin的头节点的syncronized锁,两者是互斥串行的;当写线程得到锁后,还要做doubleCheck,发现不是一开始的头节点时什么事情都不会做,发现是forwardingNode,就会加入搬运行列直到新表被提交,然后去直接操作新表。
nextTable的提交总是在所有的槽位都已经搬运完毕,插上ForwardingNode的标识之后的,因此只要新表已提交,旧表必定无法写入;这样就能够有效的避免数据写入旧表。
推理:获取到bin头节点的同步锁开始写操作----------> transfer必然未完成--------->新表必然未提交-------→写入的必然是当前表。
也就说永远不可能存在新旧两张表同时被写入的情况,table被写入时nextTable永远都只能被读取。
(3)有并发的读操作时,是否存在安全风险?
=========================
transfer操作并不破坏旧的bin结构,如果尚未开始搬运,将会照常遍历旧的BIN结构;如果已搬运完毕,会调用到forwadingNode的find方法到新表中递归查询,参考上文中的forwadingNode介绍。
九、Traverser遍历器
==================
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Java)
最后
现在其实从大厂招聘需求可见,在招聘要求上有高并发经验优先,包括很多朋友之前都是做传统行业或者外包项目,一直在小公司,技术搞的比较简单,没有怎么搞过分布式系统,但是现在互联网公司一般都是做分布式系统。
所以说,如果你想进大厂,想脱离传统行业,这些技术知识都是你必备的,下面自己手打了一份Java并发体系思维导图,希望对你有所帮助。
一个人可以走的很快,但一群人才能走的更远。如果你从事以下工作或对以下感兴趣,欢迎戳这里加入程序员的圈子,让我们一起学习成长!文章来源:https://www.toymoban.com/news/detail-852300.html
AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算文章来源地址https://www.toymoban.com/news/detail-852300.html
到现在。**
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-sdFClYwU-1712157004986)]
[外链图片转存中…(img-hdUDV3D7-1712157004987)]
[外链图片转存中…(img-SRBlUpWo-1712157004987)]
[外链图片转存中…(img-GX2apZvw-1712157004987)]
[外链图片转存中…(img-iVA8gU3o-1712157004988)]
[外链图片转存中…(img-1sR6XUWa-1712157004988)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Java)
[外链图片转存中…(img-oy3jSirL-1712157004989)]
最后
现在其实从大厂招聘需求可见,在招聘要求上有高并发经验优先,包括很多朋友之前都是做传统行业或者外包项目,一直在小公司,技术搞的比较简单,没有怎么搞过分布式系统,但是现在互联网公司一般都是做分布式系统。
所以说,如果你想进大厂,想脱离传统行业,这些技术知识都是你必备的,下面自己手打了一份Java并发体系思维导图,希望对你有所帮助。
[外链图片转存中…(img-uwKOcLAa-1712157004989)]
一个人可以走的很快,但一群人才能走的更远。如果你从事以下工作或对以下感兴趣,欢迎戳这里加入程序员的圈子,让我们一起学习成长!
AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算
到了这里,关于Java ConcurrentHashMap 高并发安全实现原理解析,字节大牛耗时八个月又一力作的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!