Java ConcurrentHashMap 高并发安全实现原理解析，mysql数据库项目式教程答案

}

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