ConcurrentHashMap深入剖析（JDK8）（下）
2018-12-11 本文已影响133人
SunnyMore
2.5 ConcurrentHashMap的put操作
首先来看下ConcurrentHashMap如何插入一个元素：
/**
* Maps the specified key to the specified value in this table.
* Neither the key nor the value can be null.
*
* <p>The value can be retrieved by calling the {@code get} method
* with a key that is equal to the original key.
*
* @param key key with which the specified value is to be associated
* @param value value to be associated with the specified key
* @return the previous value associated with {@code key}, or
* {@code null} if there was no mapping for {@code key}
* @throws NullPointerException if the specified key or value is null
*/
public V put(K key, V value) {
return putVal(key, value, false);
}
put方法中调用了putVal这个私有方法
/**
* 实际的插入操作
* onlyIfAbsent为true, 仅当key不存在时，才插入
* Implementation for put and putIfAbsent
* */
final V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException(); // 不允许key、value为空
int hash = spread(key.hashCode()); // 再次计算hash值 返回(h^(h>>>16))&HASH_BITS
/**
* 使用链表保存时，binCount记录table[i]这个桶中所保存的节点数；
* 使用红黑树保存时，binCount==2，保证put后更改计数值时能够进行扩容检查，同时不触发红黑树化操作
*/
int binCount = 0;
for (Node<K,V>[] tab = table;;) { // 自旋插入节点，直到成功
Node<K,V> f; int n, i, fh;
if (tab == null || (n = tab.length) == 0) // CASE1: 首次初始化table —— 懒加载
tab = initTable();
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // CASE2: table[i]对应的桶为null
// 注意下上面table[i]的索引i的计算方式：[ key的hash值 & (table.length-1) ]
// 这也是table容量必须为2的幂次的原因，读者可以自己看下当table.length为2的幂次时，(table.length-1)的二进制形式的特点 —— 全是1
// 配合这种索引计算方式可以实现key的均匀分布，减少hash冲突
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null))) // 插入一个链表节点
break; // no lock when adding to empty bin
}
else if ((fh = f.hash) == MOVED) // CASE3: 发现ForwardingNode节点，说明此时table正在扩容，则尝试协助数据迁移
tab = helpTransfer(tab, f); //检测到正在扩容，则帮助其扩容
else { // CASE4: 出现hash冲突,也就是table[i]桶中已经有了节点
V oldVal = null;
synchronized (f) { // 锁住table[i]节点
if (tabAt(tab, i) == f) { // 再判断一下table[i]是不是第一个节点, 防止其它线程的写修改
if (fh >= 0) { // CASE4.1: table[i]是链表节点
binCount = 1;
for (Node<K,V> e = f;; ++binCount) {
K ek;
// // 找到“相等”的节点，判断是否需要更新value值
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent) //仅putIfAbsent()方法中onlyIfAbsent为true
e.val = value; //putIfAbsent()包含key则返回get，否则put并返回
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) { // CASE4.2: table[i]是红黑树节点
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) //实则是>8,执行else,说明该桶位本就有Node
treeifyBin(tab, i); // 链表 -> 红黑树 转换
if (oldVal != null) // 表明本次put操作只是替换了旧值，不用更改计数值
return oldVal;
break;
}
}
}
addCount(1L, binCount); // 计数值加1
return null;
}
putVal的逻辑还是很清晰的，首先根据key计算hash值，然后通过hash值与table容量进行运算，计算得到key所映射的索引-----也就是对应到table中桶的位置。
这里需要注意的是计算索引的方式：i = (n - 1) & hash
(n - 1) == table.length -1, table.length的大小必须为2的幂次的原因就在这里。
大家可以自己计算下，当table.length为2的幂次时， (table.length -1)的二进制形式的特点是除最高位外全部是1，配合这种索引计算方式可以实现key在table的均匀分配，减少hash冲突------出现哈hash冲突时，节点就需要以链表或红黑树的形式链接到table[i]， 这样无论是插入还是查找都需要额外的时间。
putVal方法一共处理需要四种情况：
1. 首次初始化table------懒加载
之前讲构造器的时候说了，ConcurrentHashMap在构造的时候并不会初始化table数组，首次初始化就在这里通过initTable方法完成：
/**
* 初始化table, 使用sizeCtl作为初始化容量.
* Initializes table, using the size recorded in sizeCtl.
*/
private final Node<K,V>[] initTable() {
Node<K,V>[] tab; int sc;
while ((tab = table) == null || tab.length == 0) { //自旋直到初始化成功
if ((sc = sizeCtl) < 0) // sizeCtl<0 说明其他线程正在初始化，此线程挂起
Thread.yield(); // lost initialization race; just spin
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) { //CAS方法把sizectl置为-1，表示本线程正在进行初始化
try {
if ((tab = table) == null || tab.length == 0) {
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = tab = nt;
sc = n - (n >>> 2); // n - (n >>> 2) = n - n/4 = 0.75n, 前面说了loadFactor已在JDK1.8废弃
}
} finally {
sizeCtl = sc; // 设置threshold = 0.75 * table.length
}
break;
}
}
return tab;
}
initTable方法就是讲sizeCtl字段的值(ConcurrentHashMap对象在构造时设置)作为table的大小。需要注意的是这里的n - (n >>> 2)，其实就是0.75 * n， sizeCtl的值最终需要变更为0.75 * n， 相当于设置了threshold。
2. table[i]对应的桶为空
最简单的情况，直接CAS操作占用桶table[i]即可
3. 发现ForwardingNode节点，说明此事table正在扩容，则尝试协助进行数据迁移
ForwardingNode节点是ConcurrentHashMap的五类节点之一，相当于一个占位节点，表示当前table正在进行扩容，当前线程可以尝试协助数据迁移。
扩容和数据迁移是ConcurrentHashMap中最复杂的部分，我们会在后面进行专门讨论。
4. 出现hash冲突，也就是table[i]桶中已经有了节点
当两个不同key映射到同一个table[i]桶中时，就会出现这种情况：
- 当table[i]的节点类型为Node------链表节点时，就会将新节点以“尾插法”的形式插入链表的尾部。
- 当table[i]的节点类型为TreeBin------红黑树代理节点，就会将新节点通过红黑树的插入方式插入。
putVal方法的最后，涉及将链表转换为红黑树------treeifyBin，但实际情况并非立即就会转换，当table的容量小与64时，处于性能考虑，只是对table数组扩容1倍------tryPresize：
tryPresize方法涉及扩容和数据迁移，我们在后面专门讨论。
/**
* 尝试进行 链表 -> 红黑树 的转换.
* Replaces all linked nodes in bin at given index unless table is
* too small, in which case resizes instead. 链表转树
*/
private final void treeifyBin(Node<K,V>[] tab, int index) {
Node<K,V> b; int n, sc;
if (tab != null) {
// CASE 1: table的容量 < MIN_TREEIFY_CAPACITY(64)时，直接进行table扩容，不进行红黑树转换
if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
tryPresize(n << 1); // 容量<64，则table两倍扩容，不转树了
// CASE 2: table的容量 ≥ MIN_TREEIFY_CAPACITY(64)时，进行链表 -> 红黑树的转换
else if ((b = tabAt(tab, index)) != null && b.hash >= 0) {
synchronized (b) { // 读写锁
if (tabAt(tab, index) == b) {
TreeNode<K,V> hd = null, tl = null;
for (Node<K,V> e = b; e != null; e = e.next) { // 遍历链表，建立红黑树
TreeNode<K,V> p =
new TreeNode<K,V>(e.hash, e.key, e.val,
null, null);
if ((p.prev = tl) == null)
hd = p;
else
tl.next = p;
tl = p;
}
setTabAt(tab, index, new TreeBin<K,V>(hd)); // 以TreeBin类型包装，并链接到table[index]中
}
}
}
}
}
2.6 ConcurrentHashMap的get操作
我们来看下ConcurrentHashMap如何根据key来查找一个元素：
/**
* 根据key查找对应的value值,查找不到则返回null
* Returns the value to which the specified key is mapped,
* or {@code null} if this map contains no mapping for the key.
*
* <p>More formally, if this map contains a mapping from a key
* {@code k} to a value {@code v} such that {@code key.equals(k)},
* then this method returns {@code v}; otherwise it returns
* {@code null}. (There can be at most one such mapping.)
*
* @throws NullPointerException if the specified key is null
*/
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
int h = spread(key.hashCode()); // 重新计算key的hash值
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) { //tabAt(i),获取索引i处Node
if ((eh = e.hash) == h) { // table[i]就是待查找的项，直接返回
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
else if (eh < 0) // hash值<0, 说明遇到特殊节点(非链表节点), 调用find方法查找
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;
}
get方法的逻辑很简单，首先根据key的hash值计算映射到table的哪个桶------table[i]。
- 如果table[i]的key和待查找key相同，那直接返回；
- 如果table[i]对应的节点是特殊节点(hash值小于0)，则通过find方法查找；
- 如果table[i]对应的节点是普通链表节点，则按链表方式查找。
对于查找，关键是第二种情况，不同节点的find查找方式有所不同，下面来具体看下：
Node节点的查找
当槽table[i]被普通Node节点占用，说明是链表链接的形式，直接从链表头开始查找：
/**
* 链表查找, 增加find方法辅助get方法
* Virtualized support for map.get(); overridden in subclasses.
*/
Node<K,V> find(int h, Object k) {
Node<K,V> e = this;
if (k != null) {
do {
K ek;
if (e.hash == h &&
((ek = e.key) == k || (ek != null && k.equals(ek))))
return e;
} while ((e = e.next) != null);
}
return null;
}
TreeBin节点的查找
TreeBin的查找比较特殊，我们知道当槽table[i]被TreeBin节点占用时说明链接的是一个红黑树。由于红黑树的插入，删除会涉及整个结构的调整，所以通常存在读写并发操作的时候，是需要加锁的。
ConcurrentHashMap采用了一种类似读写锁的方式：当线程持有写锁(修改红黑树)时，如果读线程需要查找，不会像传统的读写锁那样阻塞等待，而是转而以链表的形式进行查找(TreeBin本身时Node类型的子类，所有拥有Node的所有字段)
/**
* 从根节点开始遍历查找，找到“相等”的节点就返回它，没找到就返回null
* 当存在写锁时，以链表方式进行查找
* Returns matching node or null if none. Tries to search
* using tree comparisons from root, but continues linear
* search when lock not available.
*/
final Node<K,V> find(int h, Object k) {
if (k != null) {
for (Node<K,V> e = first; e != null; ) {
int s; K ek;
/**
* 两种特殊情况下以链表的方式进行查找:
* 1. 有线程正持有写锁，这样做能够不阻塞读线程
* 2. 有线程等待获取写锁，不再继续加读锁，相当于“写优先”模式
*/
if (((s = lockState) & (WAITER|WRITER)) != 0) {
if (e.hash == h &&
((ek = e.key) == k || (ek != null && k.equals(ek))))
return e;
e = e.next; // 链表形式
}
else if (U.compareAndSwapInt(this, LOCKSTATE, s,
s + READER)) { // 读线程数量加1，读状态进行累加
TreeNode<K,V> r, p;
try {
p = ((r = root) == null ? null :
r.findTreeNode(h, k, null));
} finally {
Thread w;
// 如果当前线程是最后一个读线程，且有写线程因为读锁而阻塞，则写线程，告诉它可以尝试获取写锁了
if (U.getAndAddInt(this, LOCKSTATE, -READER) ==
(READER|WAITER) && (w = waiter) != null)
LockSupport.unpark(w);
}
return p;
}
}
}
return null;
}
ForwardingNode节点的查找
ForwardingNode是一种临时节点，在扩容进行中才会出现，所以查找也在扩容的table上进行：
/**
* 在新的扩容table——nextTable上进行查找
*/
Node<K,V> find(int h, Object k) {
// loop to avoid arbitrarily deep recursion on forwarding nodes
// 查nextTable节点，outer避免深度递归
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 (;;) { // CAS算法多和死循环搭配！直到查到或null
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;
}
}
}
ReservationNode节点的查找
ReservationNode是保留节点，不保存实际数据，所以直接返回null；
Node<K,V> find(int h, Object k) {
return null;
}
2.7 ConcurrentHashMap的计数
计数原理
我们来看下ConcurrentHashMap是如何计算键值对的数目的：
/**
* {@inheritDoc}
*/
public int size() {
long n = sumCount();
return ((n < 0L) ? 0 :
(n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
(int)n);
}
size方法内部实际调用了sumCount方法：
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;
}
可以看到，最终键值对的数目其实是通过下面这个公式计算的：
ConcurrentHashMap的计数其实沿用了LongAdder分段计数的思路，只不过ConcurrentHashMap并没有在内部直接使用LongAdder，而是差不多copy了一份LongAdder类似的代码：
/**
* 计数基值,当没有线程竞争时，计数将加到该变量上。类似于LongAdder的base变量
*/
private transient volatile long baseCount;
/**
* 计数数组，出现并发冲突时使用。类似于LongAdder的cells数组
*/
private transient volatile CounterCell[] counterCells;
/**
* 自旋标识位，用于CounterCell[]扩容时使用。类似于LongAdder的cellsBusy变量
*/
private transient volatile int cellsBusy;
我们来看下CounterCell这个槽对象------出现并发冲突时，每个线程会根据自己的hash值找到对应的槽位置：
/**
* 计数槽.
* 类似于LongAdder中的Cell内部类
* A padded cell for distributing counts. Adapted from LongAdder
* and Striped64. See their internal docs for explanation.
*/
@sun.misc.Contended static final class CounterCell {
volatile long value;
CounterCell(long x) { value = x; }
}
addCount的实现
之前在putVal方法的最后，当插入一对键值对后，通过addCount方法将计数值加1：
/**
* 实际的插入操作
*
* @param onlyIfAbsent true:仅当key不存在时,才插入
*/
final V putVal(K key, V value, boolean onlyIfAbsent) {
// …
addCount(1L, binCount); // 计数值加1
return null;
}
我们来看下addCount的具体实现：
首先，如果counterCells为null，说明之前一直没有出现过冲突，直接将值累加到baseCount上；
否则，尝试更新counterCells[i]中的值，更新成功就退出。失败说明槽中也出现了并发冲突，可能涉及槽数组------counterCells的扩容，所以调用fullAddCount方法。
fullAddCount的逻辑和LongAdder中的longAccumulate几乎完全一样，后面的文章分析LongAdder再分析；
/**
* 更改计数值
* Adds to count, and if table is too small and not already
* resizing, initiates transfer. If already resizing, helps
* perform transfer if work is available. Rechecks occupancy
* after a transfer to see if another resize is already needed
* because resizings are lagging additions.
*
* @param x the count to add
* @param check if <0, don't check resize, if <= 1 only check if uncontended
*/
private final void addCount(long x, int check) {
CounterCell[] as; long b, s;
if ((as = counterCells) != null ||
!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) { // 首先尝试更新baseCount
// 更新失败,说明出现并发冲突,则将计数值累加到Cell槽
CounterCell a; long v; int m;
boolean uncontended = true;
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null || // 根据线程hash值计算槽索引
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
fullAddCount(x, uncontended); // 槽更新也失败, 则会执行fullAddCount
return;
}
if (check <= 1)
return;
s = sumCount();
}
if (check >= 0) { // 检测是否扩容
Node<K,V>[] tab, nt; int n, sc;
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))
transfer(tab, null);
s = sumCount();
}
}
}
3. ConcurrentHashMap扩容
对于ConcurrentHashMap来说，最复杂的部分其实就是扩容/数据迁移了，涉及到了多线程的协作和rehash。我们现看下正常情况，如何对一个Hash表进行扩容。
扩容思路
Hash表的扩容，一般都包含两个步骤：
1. table数组的扩容
table数组的扩容，一般就是新建一个2倍大小的槽数组，这个过程通过由一个单线程完成，且不允许出现并发。
2. 数据迁移
所谓数据迁移，就是把旧table中的各个槽中的节点重新分配到新的table中。比如，单线程情况下，可以遍历原来的table，然后put到新table中。
这一过程通常涉及到槽中key的rehash，因为key映射到桶的位置与table的大小有关，新table的大小变了，key映射的位置一般也会变化。
ConcurrentHashMap在处理rehash的时候，并不会重新计算每个key的hash值，而是利用了一种很巧妙的方法。上文已经说过，ConcurrentHashMap内部的table数组的大小必须为2的幂次，原因是key均匀分布，减少冲突，这只是其中一个原因。另一个原因就是：
当table数组的大小为2的幂次时，通过
key.hash & table.length - 1这种方式计算出的索引i，当table扩容后(2倍)，新的索引要么在原来的位置i，要么是i + n。
举个例子：
ConcurrentHashMap扩容
上图中：
扩容前，table数组大小为16，key1和key2映射到同一个索引5；
扩容后，table数组的大小变成2 * 16 = 32，key1的索引不变，key2的索引变成5 + 16 = 21。
而且还有一个特点，扩容后key对应的索引如果发生了变化，那么其变化后的索引最高位一定是1(见扩容后key2的最高位)。
这种处理方式非常利于扩容时多个线程同时进行的数据迁移操作，因为旧table的各个桶中的节点迁移不会互相影响，所以就可以用“分治”的方式，将整个table数组划分为很多部分，每一部分包含一定区间的桶，每个数据迁移线程处理各自区间中的节点，对多线程同时进行数据迁移非常有利，后面我们会详细介绍。
扩容时机
这里有个问题，ConcurrentHashMap何时发生扩容呢？上文提到过，当往Map中插入节点时，如果链表的节点数目超过一定阈值，就会触发链表 ->红黑树的转换：
if (binCount >= TREEIFY_THRESHOLD) //实则是>8,执行else,说明该桶位本就有Node
treeifyBin(tab, i); // 链表 -> 红黑树 转换
现在，我们来分析下treeifyBin这个红黑树化的操作：
/**
* 尝试进行 链表 -> 红黑树 的转换.
* Replaces all linked nodes in bin at given index unless table is
* too small, in which case resizes instead. 链表转树
*/
private final void treeifyBin(Node<K,V>[] tab, int index) {
Node<K,V> b; int n, sc;
if (tab != null) {
// CASE 1: table的容量 < MIN_TREEIFY_CAPACITY(64)时，直接进行table扩容，不进行红黑树转换
if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
tryPresize(n << 1); // 容量<64，则table两倍扩容，不转树了
// CASE 2: table的容量 ≥ MIN_TREEIFY_CAPACITY(64)时，进行链表 -> 红黑树的转换
else if ((b = tabAt(tab, index)) != null && b.hash >= 0) {
synchronized (b) { // 读写锁
if (tabAt(tab, index) == b) {
TreeNode<K,V> hd = null, tl = null;
for (Node<K,V> e = b; e != null; e = e.next) { // 遍历链表，建立红黑树
TreeNode<K,V> p =
new TreeNode<K,V>(e.hash, e.key, e.val,
null, null);
if ((p.prev = tl) == null)
hd = p;
else
tl.next = p;
tl = p;
}
setTabAt(tab, index, new TreeBin<K,V>(hd)); // 以TreeBin类型包装，并链接到table[index]中
}
}
}
}
}
上述第一个分支中，还会再对table数组的长度进行一次判断：
如果table长度小于阈值MIN_TREEIFY_CAPACITY------默认64，则会调用tryPresize方法把数组长度扩大到原来的两倍。
从代码也可以看到，链表 -> 红黑树这一转换并不是一定会进行的，table长度较小时，CurrentHashMap会首先选择扩容，而非立即转换成红黑树。
来看下tryPresize方法如何执行扩容：
/** 尝试对table数组进行扩容,tryPresize在putAll以及treeifyBin中调用
* 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) {
// 给定的容量若>=MAXIMUM_CAPACITY的一半，直接扩容到允许的最大值，否则调用函数扩容
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;
//CASE 1: table还未初始化，则先进行初始化
if (tab == null || (n = tab.length) == 0) {
n = (sc > c) ? sc : c; // 扩容阀值取较大者
// 期间没有其他线程对表操作，则CAS将SIZECTL状态置为-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); //无符号右移2位，此即0.75*n
}
} finally {
sizeCtl = sc; // 更新扩容阀值
}
}
}
// CASE2: c <= sc说明已经被扩容过了；n >= MAXIMUM_CAPACITY说明table数组已达到最大容量
else if (c <= sc || n >= MAXIMUM_CAPACITY)
break;
else if (tab == table) { // CASE3: 进行table扩容
int rs = resizeStamp(n); // 根据容量n生成一个随机数，唯一标识本次扩容操作
if (sc < 0) { // sc < 0 表明此时有别的线程正在进行扩容
Node<K,V>[] nt;
// 如果当前线程无法协助进行数据转移, 则退出
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0) //RESIZE_STAMP_SHIFT=16,MAX_RESIZERS=2^15-1
break;
// 协助数据转移, 把正在执行transfer任务的线程数加1
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
transfer(tab, nt);
}
// sc置为负数, 当前线程自身成为第一个执行transfer(数据转移)的线程
// 这个CAS操作可以保证，仅有一个线程会执行扩容
else if (U.compareAndSwapInt(this, SIZECTL, sc,
(rs << RESIZE_STAMP_SHIFT) + 2))
transfer(tab, null);
}
}
}
前两个分支比较容易理解，主要看下第三个分支------CASE3：进行table扩容
CASE3其实分为两种情况：
- 已经有其他线程正在执行扩容了，则当前线程会尝试协助“数据迁移”；(多线程并发)
- 没有其他线程正在执行扩容，则当前线程自身发起扩容。(单线程)
注意：这两种情况都是调用了transfer方法，通过第二个入参nextTab进行区分（nextTab表示扩容后的新table数组，如果为null，表示首次发起扩容）。
第二种情况下，是通过CAS和移位运算来保证仅有一个线程能发起扩容。
扩容原理
我们来看下transfer方法，这个方法可以被多个线程同时调用，也是“数据迁移”的核心操作方法：
/**
* 数据转移和扩容.
* 每个调用tranfer的线程会对当前旧table中[transferIndex-stride, transferIndex-1]位置的节点进行迁移
* Moves and/or copies the nodes in each bin to new table. See
* above for explanation.
*/
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
int n = tab.length, stride;
// stride可理解成“步长”，即数据迁移时，每个线程要负责旧table中的多少个桶；每核处理的量小于16，则强制赋值16
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
if (nextTab == null) { // initiating 首次扩容
try {
// 创建新table数组
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1]; //两倍
nextTab = nt;
} catch (Throwable ex) { // try to cope with OOME 处理内存溢出（OOME）的情况
sizeCtl = Integer.MAX_VALUE;
return;
}
nextTable = nextTab;
transferIndex = n; // [transferIndex-stride, transferIndex-1]表示当前线程要进行数据迁移的桶区间
}
int nextn = nextTab.length;
// ForwardingNode节点，当旧table的某个桶中的所有节点都迁移完后，用该节点占据这个桶
ForwardingNode<K,V> fwd = new ForwardingNode<K,V>(nextTab);
// 标识一个桶的迁移工作是否完成，advance == true 表示可以进行下一个位置的迁移
boolean advance = true; //并发扩容的关键属性,等于true,说明此节点已经处理过
// 最后一个数据迁移的线程将该值置为true，并进行本轮扩容的收尾工作
boolean finishing = false; // to ensure sweep before committing nextTab
// i标识桶索引, bound标识边界
for (int i = 0, bound = 0;;) {
Node<K,V> f; int fh;
// 每一次自旋前的预处理，主要是定位本轮处理的桶区间
// 正常情况下，预处理完成后：i == transferIndex-1，bound == transferIndex-stride
while (advance) { // 控制--i，遍历原hash表中的节点
int nextIndex, nextBound;
if (--i >= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}//TRANSFERINDEX 即用CAS计算得到的transferIndex
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) { // CASE1：当前是处理最后一个tranfer任务的线程或出现扩容冲突
int sc;
if (finishing) { // 所有桶迁移均已完成
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1); //扩容阀值设为原来的1.5倍，即现在的0.75倍
return; // 仅有的2个跳出死循环出口之一
}
// 扩容线程数减1,表示当前线程已完成自己的transfer任务
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
// 判断当前线程是否是本轮扩容中的最后一个线程，如果不是，则直接退出
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return; // 仅有的2个跳出死循环出口之一
finishing = advance = true;
/**
* 最后一个数据迁移线程要重新检查一次旧table中的所有桶，看是否都被正确迁移到新table了：
* ①正常情况下，重新检查时，旧table的所有桶都应该是ForwardingNode;
* ②特殊情况下，比如扩容冲突(多个线程申请到了同一个transfer任务)，此时当前线程领取的任务会作废，那么最后检查时，
* 还要处理因为作废而没有被迁移的桶，把它们正确迁移到新table中
*/
i = n; // recheck before commit
}
}
else if ((f = tabAt(tab, i)) == null) // CASE2：旧桶本身为null，不用迁移，直接尝试放一个ForwardingNode
advance = casTabAt(tab, i, null, fwd);
else if ((fh = f.hash) == MOVED) // CASE3：该旧桶已经迁移完成，直接跳过
advance = true; // already processed
else { // CASE4：该旧桶未迁移完成，进行数据迁移
synchronized (f) {
if (tabAt(tab, i) == f) {
Node<K,V> ln, hn; //ln原位置节点，hn新位置节点
if (fh >= 0) { // CASE4.1：桶的hash>0，说明是链表迁移
/**
* 下面的过程会将旧桶中的链表分成两部分：ln链和hn链
* ln链会插入到新table的槽i中，hn链会插入到新table的槽i+n中
*/
int runBit = fh & n; // 由于n是2的幂次，所以runBit要么是0，要么高位是1
Node<K,V> lastRun = f; // lastRun指向最后一个相邻runBit不同的节点
for (Node<K,V> p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
if (runBit == 0) {
ln = lastRun;
hn = null;
}
else {
hn = lastRun;
ln = null;
}
// 以lastRun所指向的节点为分界，将链表拆成2个子链表ln、hn
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) // 和HashMap确定扩容后的节点位置一样
ln = new Node<K,V>(ph, pk, pv, ln);
else
hn = new Node<K,V>(ph, pk, pv, hn); //新位置节点
}
setTabAt(nextTab, i, ln); // ln链表存入新桶的索引i位置
setTabAt(nextTab, i + n, hn); // hn链表存入新桶的索引i+n位置
setTabAt(tab, i, fwd); // 设置ForwardingNode占位
advance = true; // 表示当前旧桶的节点已迁移完毕
}
else if (f instanceof TreeBin) { // CASE4.2：红黑树迁移
/**
* 下面的过程会先以链表方式遍历，复制所有节点，然后根据高低位组装成两个链表；
* 然后看下是否需要进行红黑树转换，最后放到新table对应的桶中
*/
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;//lc、hc=0两计数器分别++记录原、新bin中TreeNode数量
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;
}
}
// 判断是否需要进行 红黑树 <-> 链表 的转换
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); // 设置ForwardingNode占位
advance = true; // 表示当前旧桶的节点已迁移完毕
}
}
}
}
}
}
tranfer方法的开头，会计算出一个stride变量的值，这个stride其实就是每个线程处理的桶区间，也就是步长：
// stride可理解成“步长”，即数据迁移时，每个线程要负责旧table中的多少个桶
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE;
首次扩容时，会将table数组变成原来的2倍：
if (nextTab == null) { // 首次扩容
try {
// 创建新table数组
Node<K, V>[] nt = (Node<K, V>[]) new Node<?, ?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // 处理内存溢出（OOME）的情况
sizeCtl = Integer.MAX_VALUE;
return;
}
nextTable = nextTab;
transferIndex = n; // [transferIndex-stride, transferIndex-1]表示当前线程要进行数据迁移的桶区间
}
注意上面的transferIndex变量，这是一个字段，table[transferIndex-stride, transferIndex-1]就是当前线程要进行数据迁移的桶区间：
/**
* 扩容时需要用到的一个下标变量.
*/
private transient volatile int transferIndex;
整个transfer方法几乎都在一个自旋操作中完成，从右往左开始进行数据迁移，transfer的退出点是当某个线程处理完最后的table区段——table[0,stride-1]。
transfer方法主要包含4个分支，即对4种不同情况进行处理，我们按照难易程度来解释下各个分支所做的事情：
CASE2：桶table[i]为空
当旧table的桶table[i] == null，说明原来这个桶就没有数据，那就直接尝试放置一个ForwardingNode，表示这个桶已经处理完成。
else if ((f = tabAt(tab, i)) == null) // CASE2：旧桶本身为null，不用迁移，直接尝试放一个ForwardingNode
advance = casTabAt(tab, i, null, fwd);
注：ForwardingNode我们在上文提到过，主要做占用位，多线程进行数据迁移时，其它线程看到这个桶中是ForwardingNode节点，就知道有线程已经在数据迁移了。
另外，当最后一个线程完成迁移任务后，会遍历所有桶，看看是否都是ForwardingNode，如果是，那么说明整个扩容/数据迁移的过程就完成了。
CASE3：桶table[i]已迁移完成
没什么好说的，就是桶已经用ForwardingNode节点占用了，表示该桶的数据都迁移完了。
else if ((fh = f.hash) == MOVED) // CASE3：该旧桶已经迁移完成，直接跳过
advance = true;
CASE4：桶table[i]未迁移完成
如果旧桶的数据未迁移完成，就要进行迁移，这里根据桶中节点的类型分为：链表迁移、红黑树迁移。
- 链表迁移
链表迁移的过程如下，首先会遍历一遍原链表，找到最后一个相邻runBit不同的节点。
runbit是根据key.hash和旧table长度n进行与运算得到的值，由于table的长度为2的幂次，所以runbit只可能为0或最高位为1
然后，会进行第二次链表遍历，按照第一次遍历找到的节点为界，将原链表分成2个子链表，再链接到新table的槽中。可以看到，新table的索引要么是i，要么是i+n，这里就利用了上一节说的ConcurrentHashMap的rehash特点。
- 链表迁移
if (fh >= 0) { // CASE4.1：桶的hash>0，说明是链表迁移
/**
* 下面的过程会将旧桶中的链表分成两部分：ln链和hn链
* ln链会插入到新table的槽i中，hn链会插入到新table的槽i+n中
*/
int runBit = fh & n; // 由于n是2的幂次，所以runBit要么是0，要么高位是1
Node<K, V> lastRun = f; // lastRun指向最后一个相邻runBit不同的节点
for (Node<K, V> p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
if (runBit == 0) {
ln = lastRun;
hn = null;
} else {
hn = lastRun;
ln = null;
}
// 以lastRun所指向的节点为分界，将链表拆成2个子链表ln、hn
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); // ln链表存入新桶的索引i位置
setTabAt(nextTab, i + n, hn); // hn链表存入新桶的索引i+n位置
setTabAt(tab, i, fwd); // 设置ForwardingNode占位
advance = true; // 表示当前旧桶的节点已迁移完毕
}
- 红黑树迁移
红黑树的迁移按照链表遍历的方式进行，当链表节点超过/小于阈值时，涉及红黑树<->链表的相互转换：
- 红黑树迁移
else if (f instanceof TreeBin) { // CASE4.2：红黑树迁移
/**
* 下面的过程会先以链表方式遍历，复制所有节点，然后根据高低位组装成两个链表；
* 然后看下是否需要进行红黑树转换，最后放到新table对应的桶中
*/
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;
}
}
// 判断是否需要进行 红黑树 <-> 链表 的转换
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); // 设置ForwardingNode占位
advance = true; // 表示当前旧桶的节点已迁移完毕
}
CASE1：当前是最后一个迁移任务或出现扩容冲突
我们刚才说了，调用transfer的线程会自动领用某个区段的桶，进行数据迁移操作，当区段的初始索引i变成负数的时候，说明当前线程处理的其实就是最后剩下的桶，并且处理完了。
所以首先会更新sizeCtl变量，将扩容线程数减1，然后会做一些收尾工作：
设置table指向扩容后的新数组，遍历一遍旧数组，确保每个桶的数据都迁移完成——被ForwardingNode占用。
另外，可能在扩容过程中，出现扩容冲突的情况，比如多个线程领用了同一区段的桶，这时任何一个线程都不能进行数据迁移。
if (i < 0 || i >= n || i + n >= nextn) { // CASE1：当前是处理最后一个tranfer任务的线程或出现扩容冲突
int sc;
if (finishing) { // 所有桶迁移均已完成
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
// 扩容线程数减1,表示当前线程已完成自己的transfer任务
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
// 判断当前线程是否是本轮扩容中的最后一个线程，如果不是，则直接退出
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
finishing = advance = true;
/**
* 最后一个数据迁移线程要重新检查一次旧table中的所有桶，看是否都被正确迁移到新table了：
* ①正常情况下，重新检查时，旧table的所有桶都应该是ForwardingNode;
* ②特殊情况下，比如扩容冲突(多个线程申请到了同一个transfer任务)，此时当前线程领取的任务会作废，那么最后检查时，
* 还要处理因为作废而没有被迁移的桶，把它们正确迁移到新table中
*/
i = n; // recheck before commit
}
}
