Java ConcurrentHashMap 高并发安全实现原理解析

• HashMap本身并非为多线程环境设计，永远不要尝试在并发环境下直接使用HashMap，C13Map不存在这个安全问题。

三、C13Map的字段定义

=================

C13Map的字段定义

//最大容量

private static final int MAXIMUM_CAPACITY = 1 << 30;

//默认初始容量

private static final int DEFAULT_CAPACITY = 16;

//数组的最大容量,防止抛出OOM

static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;

//最大并行度，仅用于兼容JDK1.7以前版本

private static final int DEFAULT_CONCURRENCY_LEVEL = 16;

//扩容因子

private static final float LOAD_FACTOR = 0.75f;

//链表转红黑树的阈值

static final int TREEIFY_THRESHOLD = 8;

//红黑树退化阈值

static final int UNTREEIFY_THRESHOLD = 6;

//链表转红黑树的最小总量

static final int MIN_TREEIFY_CAPACITY = 64;

//扩容搬运时批量搬运的最小槽位数

private static final int MIN_TRANSFER_STRIDE = 16;

//当前待扩容table的邮戳位,通常是高16位

private static final int RESIZE_STAMP_BITS = 16;

//同时搬运的线程数自增的最大值

private static final int MAX_RESIZERS = (1 << (32 - RESIZE_STAMP_BITS)) - 1;

//搬运线程数的标识位，通常是低16位

private static final int RESIZE_STAMP_SHIFT = 32 - RESIZE_STAMP_BITS;

static final int MOVED = -1; // 说明是forwardingNode

static final int TREEBIN = -2; // 红黑树

static final int RESERVED = -3; // 原子计算的占位Node

static final int HASH_BITS = 0x7fffffff; // 保证hashcode扰动计算结果为正数

//当前哈希表

transient volatile Node<K,V>[] table;

//下一个哈希表

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); 需要zi料+ 绿色徽【vip1024b】

     } 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);

总结

这个月马上就又要过去了，还在找工作的小伙伴要做好准备了，小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案，希望能帮助到大家

ount** 用于写操作完成后检验元素数量，如果超过了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);

总结

这个月马上就又要过去了，还在找工作的小伙伴要做好准备了，小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案，希望能帮助到大家

[外链图片转存中…(img-uZ7zgdpx-1710350188099)]

[外链图片转存中…(img-wEpkOAzp-1710350188100)]