}
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的所有权,使其他并发的写线程阻塞。