大厂之路一由浅入深、并行基础、源码分析一 “J.U.C”之collections框架：ConcurrentHashMap扩容迁移等方法的源码分析
参考文献：jdk不同版本下HashMap和ConcurrentHashMap的对比前言前言众所周知，Map是非常经典的数据结构，常用于在内存中存放数据；本篇主要想讨论 ConcurrentHashMap 这样一个并发容器，不过在讨论前，我认为有必要了解它的由来，以及它所谓的前身"HashMap"，了解其发展，有助于我们更深刻的认识 ConcurrentHashMap；如果对于HashMap不了解的
·
- 参考文献：
前言
- 众所周知，Map是非常经典的数据结构，常用于在内存中存放数据；
- 本篇主要想讨论 ConcurrentHashMap 这样一个并发容器，不过在讨论前，我认为有必要了解它的由来，以及它所谓的前身"HashMap"。了解其发展，有助于我们更深刻的认识并掌握 ConcurrentHashMap；
- 如果对于HashMap不了解的，可以先去学习HashMap；
- HashMap：
- 底层是基于 数组 + 链表(红黑树) 组成的；
- 其实在不同的jdk版本它中的实现方式变化并不是很大，尤其是jdk1.8到现在的16基本没有变化，而jdk1.7以前也是变化不大，所以我们主要关注点就是：jdk1.7➡➡ jdk1.8 的HashMap的某一方面的优化 ；
- 并发场景下：jdk1.7 中的HashMap存在的三大问题： ☪☪☪
- 数据重复；
- 死循环：
- 具体可以看一些别的博客：这一篇是有对死循环的图解，感觉不错
- 数据丢失： 在多线程下put操作时，执行addEntry(hash, key, value, i)，可能产生哈希冲突，造成数据的丢失；
- jdk1.8中的HashMap解决了两大问题：
- 解决了jdk1.7中的HashMap在并发场景下造成 死循环 的问题；
- 解决了jdk1.7中HashMap 查询效率低 的问题（通过红黑树）；
- 当然，可以用HashTable，或者Collections.synchronizedMap 来解决并发问题，但是效率不高，因此我们今天的主角就出现了！！！
【注】：
1、为什么Collections.synchronizedMap的效率不高呢？== (同步代码块)==
答：我们先看一下Collections.synchronizedMap是怎么实现线程安全的，在SynchronizedMap内部维护了一个普通对象Map，还有 排斥锁mutex，我们在调用这个方法的时候就需要传入一个Map，mutex参数可以传也可以不传。创建出synchronizedMap之后，再操作map的时候，就会对这些方法上锁(如下)，也就是我们说的同步代码块，所以性能不高;
2、为什么Hashtable的效率不高呢？
答：它对数据操作的时候都会通过synchronized上锁，也就是我们在讲synchronized说的 同步方法；
CHM类简介
- ConcurrentHashMap是jdk1.5版本JUC引入的一个同步集合工具类，这是一个线程安全的HashMap；
[注]:不同版本的ConcurrentHashMap，内部实现机制的大幅度变化主要来源于jdk1.7—>jdk1.8，因此在这里我们先说一下jdk1.7和jdk1.8下的ConcurrentHashMap有何变化。（本文所有的讨论基于jdk1.8和jdk16;差别不大，个别有差异的已经标注出来） - jdk1.7升级到1.8，ConcurrentHashMap的变化：这一对比的总结来自一位大神的总结，可以大致看看！
- 锁方面： 由分段锁（Segment继承自ReentrantLock）升级为 CAS+synchronized实现；
【注】：CAS性能很高，但是我知道synchronized性能可不咋地，为啥jdk1.8升级之后反而多了synchronized？
答：synchronized之前一直都是重量级的锁，性能差，但是后来java官方(jdk1.5还是1.6)对它进行了优化：针对 synchronized 获取锁的方式，JVM 使用了锁升级的优化方式，就是先使用偏向锁优先同一线程，然后再次获取锁，如果失败，就升级为 CAS 轻量级锁，如果失败就会短暂自旋，防止线程被系统挂起。最后如果以上都失败就升级为重量级锁。所以是一步步升级上去的，最初也是通过很多轻量级的方式锁定的（偏向锁–>CAS轻量级锁–>自旋–>重量级锁）。 - 数据结构层面： 将Segment变为了Node，减小了锁粒度，使每个Node独立，由原来默认的并发度16变成了每个Node都独立，提高了并发度；
- hash冲突： 1.7中发生hash冲突采用链表存储，1.8中先使用链表存储，后面满足条件后会转换为红黑树来优化查询；
[注]： Hashmap中的链表大小超过八个时会自动转化为红黑树，当删除小于六时重新变为链表，为啥呢？
答：根据泊松分布，在负载因子默认为0.75的时候，单个hash槽内元素个数为8的概率小于百万分之一，所以将7作为一个分水岭，等于7的时候不转换，大于等于8的时候才进行转换，小于等于6的时候就化为链表。 - 查询复杂度： jdk1.7中链表查询复杂度为O(N)，jdk1.8中红黑树优化为O(logN))；
- 锁方面： 由分段锁（Segment继承自ReentrantLock）升级为 CAS+synchronized实现；
- 我们首先看一下ConcurrentHashMap 的继承关系（第一篇参考博客的图）：
- 我们可以看出它继承了两个接口和一个抽象类：
- AbstractMap： 这是一个java.util包下的抽象类，提供Map接口的主要方法实现，以最大限度地减少实现Map这类数据结构时所需的工作量；
- 一般来讲，如果需要重复造轮子 自己来实现一个Map，那一般就是继承AbstractMap
- Serializable接口： 其实对某一个类或接口没有特别的含义，就是对其进行序列化，以方便存储或传输，有兴趣可以看一下Serializable的相关介绍；
- ConcurrentMap接口： 是在JDK1.5时随着J.U.C包引入的，这个接口其实就是提供了一些 针对Map的原子操作：
- 我们看一下其到底实现了一些什么方法：
- AbstractMap： 这是一个java.util包下的抽象类，提供Map接口的主要方法实现，以最大限度地减少实现Map这类数据结构时所需的工作量；
package java.util.concurrent;
import java.util.Map;
import java.util.Objects;
import java.util.function.BiConsumer;
import java.util.function.BiFunction;
import java.util.function.Function;
public interface ConcurrentMap<K,V> extends Map<K,V> {
//返回指定key对应的值；如果Map不存在该key，则返回defaultValue💦💦
default V getOrDefault(Object key, V defaultValue) { ...}
//遍历Map的所有Entry，并对其进行指定的aciton操作💦💦
default void forEach(BiConsumer<? super K, ? super V> action) {...}
//如果Map不存在指定的key，则插入<K,V>；否则，直接返回该key对应的值💦💦
V putIfAbsent(K key, V value);
//删除与<key,value>完全匹配的Entry，并返回true；否则，返回false💦💦
boolean remove(Object key, Object value);
//如果存在key，且值和oldValue一致，则更新为newValue，并返回true；否则，返回false💦💦
boolean replace(K key, V oldValue, V newValue);
//如果存在key，则更新为value，返回旧value；否则，返回null💦💦
V replace(K key, V value);
//遍历Map的所有Entry，并对其进行指定的funtion操作💦💦
default void replaceAll(BiFunction<? super K, ? super V, ? extends V> function) {...}
//如果Map不存在指定的key，则通过mappingFunction计算出value并插入💦💦
default V computeIfAbsent(K key , Function<? super K, ? extends V> mappingFunction{...}
//如果Map存在指定的key，则通过mappingFunction计算出value并替换旧值💦💦
default V computeIfPresent(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction) {...}
//根据指定的key，查找value；然后根据得到的value和remappingFunction重新计算出新值，并替换旧值💦💦
default V compute(K key , BiFunction<? super K, ? super V, ? extends V> remappingFunction) {...}
//如果key不存在，则插入value；否则，根据key对应的值和remappingFunction计算出新值，并替换旧值💦💦
default V merge(K key, V value , BiFunction<? super V, ? super V, ? extends V> remappingFunction) {...}
CHM基本数据结构
- 我们接下来看一下jdk1.8的ConcurrentHashMap的内部数据结构（依旧第一篇博客的图，问就是大神太强了）：
- ConcurrentHashMap内部维护了一个Node类型的数组：table
- table一共包含 4 种不同类型的桶，不同的桶用不同颜色表示，这是jdk1.8版本的特点；
[注]：TreeBin结点所连接的是一颗红黑树，红黑树的结点用TreeNode表示，所以ConcurrentHashMap中实际上一共有 五 种不同类型的Node结点；
这里我们思考一个问题，为什么没有直接用TreeNode呢？
主要是因为红黑树的操作比较复杂，包括构建、左旋、右旋、删除，平衡等操作，用一个代理结TreeBin来包含这些复杂操作，其实是一种 “职责分离”的思想，另外TreeBin中也包含了一些加/解锁操作。
- table一共包含 4 种不同类型的桶，不同的桶用不同颜色表示，这是jdk1.8版本的特点；
- 数组的每一个位置table[i]代表一个桶，当插入键值对时，会根据键的hash值映射到不同的桶位置；
- 【注】：
- 在jdk1.8之前，ConcurrentHashMap采用了分段【Segment】锁的设计思路，以减少热点域的冲突，在jdk16中依旧有内部类Segment，目的是 为了序列化以及兼容以前的jdk版本；
- jdk1.8不再延续，转而直接对每个桶加锁，并用“红黑树”链接冲突结点（有兴趣的可以看红黑树的相关讲解）；
CHM类的结点定义
- 前面一部分我们讲了ConcurrentHashMap的数据结构，知道其实它包括了 5 种结点。我们分别来看一下：
1️⃣ Node结点：- Node是其它四种类型结点的父类；
- 默认链接到table[i]，即桶上的结点就是Node结点；
- 当出现hash冲突时，Node结点会首先以链表的形式链接到table上：
- 当结点数量超过一定数目时，链表会转化为红黑树；
【注】：因为链表查找的时间复杂度为O(n)，而红黑树是一种平衡二叉树，其平均时间复杂度为O(logn)，这样就提高了效率。
- 当结点数量超过一定数目时，链表会转化为红黑树；
/*
* 普通的Entry结点, 以链表形式保存时才会使用, 存储实际的数据.
*/
static class Node<K,V> implements Map.Entry<K,V> {
final int hash; //通过key计算hash值，通过hash值找相应的桶
final K key;
volatile V val; //volatile修饰，保证可见性、有序性、但和原子性可没什么关系
volatile Node<K,V> next; //volatile修饰,链表指针💛
Node(int hash, K key, V val) { //构造器
this.hash = hash;
this.key = key;
this.val = val;
}
Node(int hash, K key, V val, Node<K,V> next) {
this(hash, key, val);
this.next = next;
}
public final K getKey() { return key; }
public final V getValue() { return val; }
public final int hashCode() { return key.hashCode() ^ val.hashCode(); }
//这里我放的jdk16版本，Helpers我并不太了解，但看其源码就是为JUC包下的一个工具类，帮助toString，如果以后深入了解，再来纠正
public final String toString() { return Helpers.mapEntryToString(key, val); }
public final V setValue(V value) { throw new UnsupportedOperationException(); }
public final boolean equals(Object o) {
Object k, v, u; Map.Entry<?,?> e;
return ((o instanceof Map.Entry) &&
(k = (e = (Map.Entry<?,?>)o).getKey()) != null &&
(v = e.getValue()) != null &&
(k == key || k.equals(key)) &&
(v == (u = val) || v.equals(u)));
}
//链表查找，不同类型的结点有不同的find()方法🧡
Node<K,V> find(int h, Object k) {...}
2️⃣ TreeNode结点：
- TreeNode是红黑树的结点，TreeNode不会直接链接到桶上面，而是由TreeBin链接，TreeBin会指向红黑树的根结点;
// 红黑树结点，存储实际数据
static final class TreeNode<K,V> extends Node<K,V> {
TreeNode<K,V> parent; // red-black tree links 红黑树链接
TreeNode<K,V> left;
TreeNode<K,V> right;
/* needed to unlink next upon deletion ，prev指针是为了方便删除，
删除链表的非头结点时，需要知道它的前驱结点才能删除，所以直接提供一个prev指针
*/
TreeNode<K,V> prev;
boolean red;
TreeNode(int hash, K key, V val, Node<K,V> next , TreeNode<K,V> parent) {
super(hash, key, val, next);
this.parent = parent;
}
Node<K,V> find(int h, Object k) {
return findTreeNode(h, k, null);
}
//以当前结点（this）为根结点，开始遍历查找指定key.
final TreeNode<K,V> findTreeNode(int h, Object k, Class<?> kc) {...}
3️⃣TreeBin结点： (hash = -2)
- TreeBin相当于TreeNode的代理结点；TreeBin会直接链接到 table[i] 上，该结点提供了一系列红黑树相关的操作，以及加锁、解锁操作：
/*
TreeNode的代理结点（相当于封装了TreeNode的容器，提供针对红黑树的转换操作和锁控制）
hash值固定为-2
*/
static final class TreeBin<K,V> extends Node<K,V> {
TreeNode<K,V> root; // 红黑树结构的根结点
volatile TreeNode<K,V> first; // 链表结构的头结点
volatile Thread waiter; // 最近的一个设置WAITER标识位的线程
volatile int lockState; // 整体的锁状态标识位，0为初始态
// values for lockState
static final int WRITER = 1; // 二进制001，红黑树的写锁状态
static final int WAITER = 2; // 二进制010，红黑树的等待获取写锁状态（优先锁，当有锁等待，读就不能增加了）
// 二进制100，红黑树的读锁状态，读可以并发，每多一个读线程，lockState都加上一个READER值，
static final int READER = 4;
/*
在hashCode相等并且不是Comparable类型时，用此方法判断大小.
*/
static int tieBreakOrder(Object a, Object b) {
int d;
if (a == null || b == null ||
(d = a.getClass().getName().
compareTo(b.getClass().getName())) == 0)
d = (System.identityHashCode(a) <= System.identityHashCode(b) ? -1 : 1);
return d;
}
// 将以b为头结点的链表转换为红黑树
TreeBin(TreeNode<K,V> b) {...}
// 通过lockState,对红黑树的根结点➕写锁.
private final void lockRoot() {
if (!U.compareAndSetInt(this, LOCKSTATE, 0, WRITER))
contendedLock(); // offload to separate method ，Possibly blocks awaiting root lock.
}
//释放写锁
private final void unlockRoot() { lockState = 0; }
// 从根结点开始遍历查找，找到“相等”的结点就返回它，没找到就返回null，当存在写锁时，以链表方式进行查找，后会面会介绍
final Node<K,V> find(int h, Object k) {... }
/**
* 查找指定key对应的结点,如果未找到，则直接插入.
* @return 直接插入成功返回null, 替换返回找到的结点的oldVal
*/
final TreeNode<K,V> putTreeVal(int h, K k, V v) {...}
/*
删除红黑树的结点：
1. 红黑树规模太小时，返回true，然后进行 树 -> 链表 的转化，最后删除;
2. 红黑树规模足够时，不用变换成链表，但删除结点时需要加写锁;
*/
final boolean removeTreeNode(TreeNode<K,V> p) {...}
// 以下是红黑树的经典操作方法，改编自《算法导论》💦💦💦💦
static <K,V> TreeNode<K,V> rotateLeft(TreeNode<K,V> root , TreeNode<K,V> p) { ...}
static <K,V> TreeNode<K,V> rotateRight(TreeNode<K,V> root , TreeNode<K,V> p) {...}
static <K,V> TreeNode<K,V> balanceInsertion(TreeNode<K,V> root , TreeNode<K,V> x) {...}
static <K,V> TreeNode<K,V> balanceDeletion(TreeNode<K,V> root, TreeNode<K,V> x) { ... }
static <K,V> boolean checkInvariants(TreeNode<K,V> t) {...} //递归检查红黑树的正确性
private static final long LOCKSTATE= U.objectFieldOffset(TreeBin.class, "lockState");
}
4️⃣ForwardingNode结点: (hash = -1)
- ForwardingNode结点仅仅在 扩容 时才会使用
/**
* ForwardingNode是一种临时结点，在扩容进行中才会出现，hash值固定为-1，且不存储实际数据。
* 如果旧table数组的一个桶table[i]中全部的结点都迁移到了新table中，则在这个桶中放置一个ForwardingNode,
即table[i]=ForwardingNode。
* 读操作碰到ForwardingNode时，将操作转到扩容后的新table数组上去执行---》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;
}
// 在新的数组(nextTable)上进行查找
Node<K, V> find(int h, Object k) {...}
5️⃣ReservationNode结点 （hash=-3）
/**
* 保留结点.
* hash值固定为-3， 不保存实际数据
* 只在computeIfAbsent和compute这两个函数式API中充当占位符加锁使用
*/
static final class ReservationNode<K, V> extends Node<K, V> {
ReservationNode() {
super(RESERVED, null, null, null);
}
Node<K, V> find(int h, Object k) {
return null;
}
}
CHM类的构造器
- ConcurrentHashMap提供了五个构造器：
- 这五个构造器内部最多只是计算了下table的初始容量大小，并没有进行实际的创建table数组的工作：
【注】：这时候有一个问题：什么时候创建table数组呢？
答：ConcurrentHashMap采用了一种“懒加载”的模式，只有到首次插入键值对的时候，才会真正的去初始化table数组；
- 这五个构造器内部最多只是计算了下table的初始容量大小，并没有进行实际的创建table数组的工作：
- 接下来我们分别看一下这五个构造器：
//💕空构造器💕:
public ConcurrentHashMap() { }
//💕💕指定table初始容量的构造器💕💕
/**
* 指定table初始容量的构造器.
* tableSizeFor会返回大于入参（initialCapacity + (initialCapacity >>> 1) + 1）的最小2次幂值,也就是说初始值
* 必须是2的整数倍，并且不能过小
*/
public ConcurrentHashMap(int initialCapacity) {
if (initialCapacity < 0)
throw new IllegalArgumentException();
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ? MAXIMUM_CAPACITY :
tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
this.sizeCtl = cap;
}
//💕💕💕根据已有的Map构造💕💕💕
/**
* 根据已有的Map构造ConcurrentHashMap.
*/
public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
this.sizeCtl = DEFAULT_CAPACITY;
putAll(m);
}
//💕💕💕💕指定table初始容量和负载因子的构造器💕💕💕💕
/**
* 指定table初始容量和负载因子的构造器.
*/
public ConcurrentHashMap(int initialCapacity, float loadFactor) {
this(initialCapacity, loadFactor, 1);
}
//💕💕💕💕💕指定table初始容量、负载因子、并发级别的构造器💕💕💕💕💕
/**
* 指定table初始容量、负载因子、并发级别的构造器.
* 注意：concurrencyLevel只是为了兼容JDK1.8以前的版本，并不是实际的并发级别，loadFactor也不是实际的负载因子
* 这两个都失去了原有的意义，仅仅对初始容量有一定的控制作用
*/
public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (initialCapacity < concurrencyLevel)
initialCapacity = concurrencyLevel;
long size = (long) (1.0 + (long) initialCapacity / loadFactor);
int cap = (size >= (long) MAXIMUM_CAPACITY) ?
MAXIMUM_CAPACITY : tableSizeFor((int) size);
this.sizeCtl = cap;
}
CHM类的属性
- 常量 :
//最大容量.
private static final int MAXIMUM_CAPACITY = 1 << 30;
//默认初始容量
private static final int DEFAULT_CAPACITY = 16;
static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
//负载因子，为了兼容JDK1.8以前的版本而保留，JDK1.8中的ConcurrentHashMap的负载因子恒定为0.75
private static final float LOAD_FACTOR = 0.75f;
//链表--->树的阈值:即链接结点数大于8时， 链表转换为树.
static final int TREEIFY_THRESHOLD = 8;
//树--->链表的阈值:即树结点树小于6时，树转换为链表.
static final int UNTREEIFY_THRESHOLD = 6;
/**
* 在链表--->树之前，还会有一次判断：
* 即只有键值对数量大于MIN_TREEIFY_CAPACITY，才会发生转换。
* 这是为了避免在Table建立初期，多个键值对恰好被放入了同一个链表中而导致不必要的转化。
*/
static final int MIN_TREEIFY_CAPACITY = 64;
/**
* 在树--->链表之前，还会有一次判断：
* 即只有键值对数量小于MIN_TRANSFER_STRIDE，才会发生转换.
*/
private static final int MIN_TRANSFER_STRIDE = 16;
//用于在扩容时生成唯一的随机数.
private static int RESIZE_STAMP_BITS = 16;
//可同时进行扩容操作的最大线程数.
private static final int MAX_RESIZERS = (1 << (32 - RESIZE_STAMP_BITS)) - 1;
/**
* The bit shift for recording size stamp in sizeCtl.
*/
private static final int RESIZE_STAMP_SHIFT = 32 - RESIZE_STAMP_BITS;
/*
* hash值的意义
*/
static final int MOVED = -1; // 标识ForwardingNode结点（在扩容时才会出现，不存储实际数据）
static final int TREEBIN = -2; // 标识红黑树的根结点
static final int RESERVED = -3; // 标识ReservationNode结点（）
static final int HASH_BITS = 0x7fffffff; // 标识Node结点，自然数0，1，2...
//CPU核心数，扩容时使用
static final int NCPU = Runtime.getRuntime().availableProcessors();
- 字段 :
//Node数组，标识整个Map，首次插入元素时创建，大小总是2的幂次.
transient volatile Node<K, V>[] table;
//扩容后的新Node数组，只有在扩容时才非空.
private transient volatile Node<K, V>[] nextTable;
/**
* sizeCtl：控制table的初始化和扩容.很重要💦💦💦💦
* 0 : 初始默认值
* -1 : 有线程正在进行table的初始化
* >0 : table初始化时使用的容量，或初始化/扩容完成后的阈值threshold
* -(1 + nThreads) : 记录正在执行扩容任务的线程数
*/
private transient volatile int sizeCtl;
//扩容时需要用到的一个下标变量.
private transient volatile int transferIndex;
//计数基值,当没有线程竞争时，计数将直接加到该变量上。类似于LongAdder的base变量
private transient volatile long baseCount;
//计数数组，出现并发冲突时使用，这时候计数不能直接加到baseCount变量上，类似于LongAdder的cells数组
private transient volatile CounterCell[] counterCells;
// 自旋标识位，用于CounterCell[]扩容时使用。类似于LongAdder的cellsBusy变量
private transient volatile int cellsBusy;
// 视图相关字段
private transient KeySetView<K, V> keySet;
private transient ValuesView<K, V> values;
private transient EntrySetView<K, V> entrySet;
CHM类的put()源码解析💦💦
- put方法是ConcurrentHashMap类的核心方法，也是我们必须要理解的，接下来让我们看一下它是如何操作的：
/*
插入键值对，<K,V>均不能为null.
*/
public V put(K key, V value) {
return putVal(key, value, false);
}
- 其内部调用了putVal(K key, V value, boolean onlyIfAbsent) (default)
[注]：
1、为什么concurrentHashMap、Hashtable等不允许key/value为null呢？而HashMap可以呢？
答：（有大佬能更好的解释，我再改正）
原因1：这是因为ConcurrentHashMap和Hashtable都是支持并发的，这样会有一个问题，当你通过get(k)获取对应的value时，如果获取到的是null时，你无法判断，它是put（k,v）的时候value就为null，还是这个key从来没有做过映射。
而HashMap是非并发的，可以通过contains(key)来进行校验。而支持并发的Map在调用m.contains（key）和m.get(key)时m可能已经不同了
2、什么是快速失败机制（fail-fast）呢？
答：在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出 Concurrent Modification Exception。
2.1快速失败机制（fail-fast）的原理是啥？
答：迭代器在遍历时直接访问集合中的内容，在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。 每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedmodCount值，是的话就返回遍历；否则抛出Concurrent Modification Exception异常，终止遍历。 (注意：不能依赖于这个异常是否抛出而进行并发操作的判断，因为会有类似CAS操作的“ABA”问题，所以这个异常只建议用于检测并发修改的bug)。
3、什么是安全失败机制（fail—safe）呢？
答：采用安全失败机制的集合容器，在遍历时不是直接在集合上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。由于循环的时候是对原集合的“复制品”进行遍历，所以在你遍历的过程中对原集合的更改都不会被迭代器检测到，所以不会报错。
4、快速失败机制（fail-fast）和安全失败机制（fail—safe）的适用场所呢？
答：
java.util包下的集合类都是快速失败（fail-fast）的，不能在多线程下发生并发修改（迭代过程中被修改）算是一种安全机制，但是预防不了 ABA问题；
java.util.concurrent包下的容器都是安全失败（fail—safe），可以在多线程下并发使用，并发修改，不过要想适用于并发场景，需要额外的控制管理； - 一不小心说多了，接着往下看：
/**
* 实际的插入操作
* @param onlyIfAbsent true:仅当key不存在时,才插入
*/
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值,防止并发情况的影响
// static final int spread(int h) { return (h ^ (h >>> 16)) & HASH_BITS;}
/*
* binCount 的用法：
* 1、使用链表保存时，binCount记录table[i]这个桶中所保存的结点数；
* 2、使用红黑树保存时，binCount==2，保证put后更改计数值时能够进行扩容检查，同时不触发红黑树化操作
*/
int binCount = 0;
// 自旋插入结点，直到成功
for (Node<K, V>[] tab = table; ; ) {
Node<K, V> f;
int n, i, fh;
// CASE1: 首次初始化table —— 懒加载💦💦💦
if (tab == null || (n = tab.length) == 0)
tab = initTable();
// CASE2: table[i]对应的桶为null，则直接插入结点💦💦💦
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
// [注]：上面table[i]的索引i的计算方式：[ key的hash值 & (table.length-1) ],为什么要这样计算呢？
// 配合这种索引计算方式可以实现key的均匀分布，减少hash冲突（前提table容量必须为2的幂次，这也是为什么容量必须是2的幂次的原因）
//tabAt(tab, i)方法是调用Unsafe类的方法查看值，保证每次获取到的值都是最新的
if (casTabAt(tab, i, null, new Node<K, V>(hash, key, value, null))) // cas操作：插入一个链表结点，成功返回
break;
// CASE3: 发现ForwardingNode结点（通过MOVED标识ForwardingNode结点存在），说明此时table正在扩容，则尝试协助数据迁移💦💦💦
} else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f); //这个方法后面会详细介绍，很重要🧡🧡🧡
// CASE4: 出现hash冲突,也就是table[i]桶中已经有了结点💦💦💦
else {
V oldVal = null;
synchronized (f) { // 对table[i]结点上锁，避免并发情况
if (tabAt(tab, i) == f) { // 再判断一下节点 是不是在这个 table[i]上
//static final int HASH_BITS = 0x7fffffff; // 标识Node结点，自然数
//CASE4.1: （fh >= 0）--->table[i]是链表结点💦
if (fh >= 0) {
binCount = 1; //记录结点数，超过阈值后，需要转为红黑树，提高查找效率
for (Node<K, V> e = f; ; ++binCount) {
K ek;
// 找到“相等”的结点，判断是否需要更新value值（onlyIfAbsent为false则可以插入）
if (e.hash == hash && ((ek = e.key) == key || (ek != null && key.equals(ek)))) {
oldVal = e.val; //记录key冲突的原来对应的value值
if (!onlyIfAbsent) //onlyIfAbsent标志仅当不存在时才插入
e.val = value;
break;
}
//如果没有找到，则直接插在尾部即可
Node<K, V> pred = e;
if ((e = e.next) == null) { // “尾插法”插入新结点
pred.next = new Node<K, V>(hash, key,value, null);
break;
}
}
// CASE4.2: 上面判断不是链表结点，则继续判断table[i]是不是红黑树结点💦
} else if (f instanceof TreeBin) {
Node<K, V> p;
binCount = 2; //红黑树对应的基值，我认为哈是包括了treebin和root，所以以2为基础
if ((p = ((TreeBin<K, V>) f).putTreeVal(hash, key, value)) != null) { //插入
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
// CASE4.3: 不是链表节点也不是红黑树结点，则看是不是ReservationNode结点用于计算用的💦（jdk1.8版本没有这个判断）
}else if (f instanceof ReservationNode)
throw new IllegalStateException("Recursive update");
}
}
if (binCount != 0) {
if (binCount >= TREEIFY_THRESHOLD) // 超过阈值，链表 -> 红黑树 转换，💦💦添加节点后转化💦💦💦
treeifyBin(tab, i);
if (oldVal != null) // 表明本次put操作只是替换了旧值，不用更改计数值
return oldVal;
break;
}
}
}
addCount(1L, binCount); //表明本次操作增加了新值， 计数值加1
return null;
}
- 其实我们可以发现，putVal(K key, V value, boolean onlyIfAbsent) 的逻辑很清晰的：
- 首先根据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]，这样无论是插入还是查找都需要额外的时间。
- 计算索引的方式是
- 我们通过一个流程图进一步看这个方法（很不容易的！！！大哥们好好看看！！）：
CHM类的putVal()中的四种情况💦💦
1️⃣、首次初始化table —— 懒加载
- 之前分析构造器的时候以及put()源码的注释中都说了，ConcurrentHashMap在构造的时候并不会始化table数组，首次初始化就在这里通过 initTable（） 完成：
【注】：如果多个线程同时调用initTable初始化Node数组怎么办？让我们看并发编程大师Doug Lea的源码：
答：在初始化数组时使用了乐观锁CAS操作来决定到底是哪个线程有资格进行初始化；
volatile变量（sizeCtl）：它是一个标记位，用来告诉其他线程这个坑位有没有人在，其线程间的可见性由volatile保证，CAS操作保证了设置sizeCtl标记位的原子性，保证了只有一个线程能设置成功
/**
* 初始化table, 使用sizeCtl作为初始化容量.
*/
private final Node<K, V>[] initTable() {
Node<K, V>[] tab;
int sc;
while ((tab = table) == null || tab.length == 0) { //自旋直到初始化成功（每次循环都获取最新的Node数组引用）
if ((sc = sizeCtl) < 0) // sizeCtl<0 ：说明table已经正在初始化/扩容，所以让出CPU时间片
Thread.yield();
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) { // 将sizeCtl更新成-1,表示正在初始化中
//如果CAS操作成功了，代表本线程将负责初始化工作
try {
//再次检查table数组是否为空
if ((tab = table) == null || tab.length == 0) {
//在初始化Map时，sizeCtl代表数组大小，默认16，所以此时n默认为16
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
Node<K, V>[] nt = (Node<K, V>[]) new Node<?, ?>[n]; //Node数组nt
table = tab = nt; //将nt其赋值给table,tab变量
sc = n - (n >>> 2); // n - (n >>> 2) = n - n/4 = 0.75n(前面说了loadFactor已在JDK1.8废弃)
}
} finally {
//将计算后的sc（12）直接赋值给sizeCtl，表示达到12长度就扩容,由于这里只会有一个线程在执行，直接赋值即可，没有线程安全问题
//只需要保证可见性
sizeCtl = sc;
}
break;
}
}
return tab;
}
- initTable()： 将sizeCtl字段的值（ConcurrentHashMap对象在构造时设置）作为table的大小（其实这里就是默认值，因为创造前先用CAS操作将sizeCtl变为-1了）；
* 【注】：这里的n - (n >>> 2)，其实就是0.75 * n，sizeCtl 的值最终需要变更为0.75 * n，相当于设置了阈值threshold；
2️⃣、table[i]对应的桶为空： 直接CAS操作占用桶table[i]；
3️⃣、发现ForwardingNode结点，说明此时table正在扩容，则尝试协助进行数据迁移；
- ForwardingNode结点是ConcurrentHashMap中的五类结点之一，相当于一个占位结点，表示当前table正在进行扩容，当前线程可以尝试协助数据迁移；
- 后面会对helpTransfer()调用的核心方法transfer()进行分析，我这里简单了解一下helpTransfer()：
final Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) {
Node<K,V>[] nextTab; int sc;
if (tab != null && (f instanceof ForwardingNode) &&
(nextTab = ((ForwardingNode<K,V>)f).nextTable) != null) {
int rs = resizeStamp(tab.length);
while (nextTab == nextTable && table == tab && (sc = sizeCtl) < 0) {
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 || sc == rs + MAX_RESIZERS || transferIndex <= 0)
break;
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)) { //sizeCtl加一，表示多一个线程进来协助扩容
transfer(tab, nextTab); //扩容，后面详细讲解
break;
}
}
return nextTab;
}
return table;
}
- 此方法涉及大量复杂的位运算，我们简单了解即可（主要是我看别的博客没怎么分析，我就没有过多深究，有点不思进取，哈哈哈~），此时sizeCtl变量用来标示HashMap正在扩容，当其准备扩容时，会将sizeCtl设置为一个负数，（例如数组长度为16时）其二进制表示为：
1000 0000 0001 1011 0000 0000 0000 0010
- 这个二进制表示什么呢（我们将其分成：高16位、低16位）？
答：
高16位：其中最高位表示符号位，1表示负数，其余的表示数组长度的一个位算法标示（有点像epoch的作用，表示当前迁移朝代为数组长度X）
低16位：表示有几个线程正在做迁移，刚开始为2，线程迁移完成会使其进行-1操作，那为什么刚开始的 时候为2呢？这也是我们在前面分析字段中的sizeCt l -(1 + nThreads) : 记录正在执行扩容任务的线程数，也就是说如果为2的时候代表就一个线程正在做迁移。==
4️⃣、出现hash冲突,也就是table[i]桶中已经有了结点
- 当两个不同key映射到同一个 table[i] 桶中时，就会出现这种情况：
- 当table[i]的结点类型为Node——链表结点时，就会将新结点以“尾插法”的形式插入链表的尾部；
- 当table[i]的结点类型为TreeBin——红黑树代理结点时，就会将新结点通过红黑树的插入方式插入；
- 到此，我们的put方法就告一段落，至于扩容和迁移我们后面详细讲：
CHM的get()源码分析：
- ConcurrentHashMap最常用，最重要的方法：一个是put()一个是get()，既然put() 分析的差不多了，那我们接下来看看get():
【注】：假设桶table[3]的节点正在迁移，突然有一个线程进来调用get方法，正好key又散列到桶table[3]，此时怎么办?
答：这时其hash为MOVED，即-1，所以此时判断线程正在迁移，这时候用find方法去查找值;
/**
* 根据key查找对应的value值
* @return 查找不到则返回null
* @throws NullPointerException 如果key为空，则抛出异常
*/
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值
//(e = tabAt(tab, (n - 1) & h)) != null找到对应的桶
if ((tab = table) != null && (n = tab.length) > 0 && (e = tabAt(tab, (n - 1) & h)) != null) {
//CASE1：看table[i]当前节点是不是要找的值
if ((eh = e.hash) == h) { // table[i]就是待查找的桶，直接找值
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
//CASE2：当前节点不是，则判断是不是特殊节点，如果是find查找
} else if (eh < 0) // hash值 < 0 , 说明遇到特殊结点(非链表结点), 调用find方法查找
return (p = e.find(h, key)) != null ? p.val : null;
//CASE3：当前不是特殊节点，则链表遍历查找
while ((e = e.next) != null) { // 遍历table[i]中的结点，因为前面通过eh判断过不是特殊节点了，则直接按链表查找
if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
- 通过源码对比，我们发现 get() 方法相比 put() 要简单许多，我们接下来再描述一遍其流程：
- 首先：根据key的hash值计算映射到table的哪个桶，table[i]；
- 其次：如果table[i]的key和待查找key相同，那直接返回（这时候不用判断是不是特殊节点）；
- 最后：如果table[i]对应的结点是特殊结点（hash值小于0），则通过 find() 查找，如果不是特殊节点，则按链表查找；
- 用一个类比说：就是先找桶，找到桶，看桶上的结点是不是自己需要的的，如果是就不用打开桶了，直接返回，如果不是我们就看桶里面的结点是不是，而打开桶的方式有两种，一种就是平常的按链表找，另一种就是借助工具 find() 找；
- 接下来，我们看一下这个工具，不同的结点有不同的实现方式呢(是不是感觉很矫情)~
CHM的find()源码分析：
- 上文已经说过，不同的结点有不同的find()实现，这里的find()，是去新数组newtable中查找的 接下来我们就分别看一下：
①： Node结点的查找 （hash>=0
- 当 槽table[i] 被普通Node结点占用，说明是链表链接的形式，直接从链表头开始查找：
/*
* 链表查找.
* h:hash
* k:key
*/
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结点的查找 （hash=-2） 💦💦💦
-
TreeBin的查找比较特殊，我们知道当桶table[i]被TreeBin结点占用时，说明链接的是一棵红黑树；
- 由于红黑树的插入、删除等操作会涉及整个结构的调整，所以通常存在读写并发操作的时候，是需要加锁的；
【注】：ConcurrentHashMap采用了一种类似读写锁的方式：当线程持有写锁（修改红黑树）时，如果读线程需要查找，不会像传统的读写锁那样阻塞等待，而是转而以链表的形式进行查找（TreeBin本身是Node类型的子类，所有拥有Node的所有字段），并在最后如果有写线程等待则唤醒写线程 💦💦💦
/**
* 从根结点开始遍历查找，找到“相等”的结点就返回它，没找到就返回null
* 当存在写锁或等待获取写锁时，以链表方式进行查找
* 也就是说，只有读锁时，才红黑树查找
*/
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. WRITER---》有线程正持有写锁，这样做能够不阻塞读线程
* 2. WAITER ---》有线程等待获取写锁，不再继续加读锁，相当于“写优先”模式
*/
if (((s = lockState) & (WAITER | WRITER)) != 0) {
if (e.hash == h && ((ek = e.key) == k || (ek != null && k.equals(ek))))
return e;
e = e.next; // 链表形式查找，找到立即返回
}
//这时候就是按红黑树找了，读线程数量加1(读读)，读状态进行累加, READER==4
else if (U.compareAndSwapInt(this, LOCKSTATE, s, s + READER)) {
TreeNode<K, V> r, p;
try {
p = ((r = root) == null ? null : r.findTreeNode(h, k, null)); //红黑树的根节点非空才能找
} finally {
Thread w;
// 如果去除当前读线程状态，LOCKSTATE依旧表示为有写线程w因为读锁而阻塞并有读线程，则告诉写线程，它可以尝试获取写锁了，就是条件2
if (U.getAndAddInt(this, LOCKSTATE, -READER) == (READER | WAITER) && (w = waiter) != null)
LockSupport.unpark(w);
}
return p;
}
}
}
return null;
}
③ ：ForwardingNode结点的查找 （hash=-1）
- ForwardingNode是一种临时结点，在扩容进行中才会出现，所以查找也在扩容的table ----》nextTable 上进行 (链表遍历)：
/**
* 在新的扩容table—-》nextTable上进行查找
*/
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;
}
}
}
④ ：ReservationNode结点的查找
- ReservationNode是保留结点，不保存实际数据，所以直接返回null：
Node<K, V> find(int h, Object k) { return null; }
CHM的计数相关方法：
- 接下来，我们看一下ConcurrentHashMap是如何计算键值对的数目的：
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;
}
- 可以看到，最终键值对的数目其实是通过下面这个公式计算的：
[注]:这里可以看一下LongAdder，这也是第一篇参考文章的博主写的，这就是ConcurrentHashMap的计数思路：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值找到对应的槽位置：
【注】：在设计中，使用了分而治之的思想，将每一个计数都分散到各个countCell对象里面，使竞争最小化，又使用了CAS操作，就算有竞争，也可以对失败了的线程进行其他的处理。乐观锁的实现方式与悲观锁不同之处就在于乐观锁可以对竞争失败了的线程进行其他策略的处理，而悲观锁只能等待锁释放，所以这里使用CAS操作对竞争失败的线程做了其他处理，很巧妙的运用了CAS乐观锁。
/**
* 计数槽.
* 类似于LongAdder中的Cell内部类
*/
static final class CounterCell {
volatile long value;
CounterCell(long x) {
value = x;
}
}
CHM的addCount()源码分析
- 之前的putval() 的最后，当插入新的结点后，通过 addCount() 将计数值为加1，我们接下来看看 addCount() 的具体实现：
/**
* 更改计数值，并检查长度是否达到阈值
*/
private final void addCount(long x, int check) {
CounterCell[] as; //计数桶
long b, s;
// !U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)：尝试更新baseCount
//1、如果counterCells不为null，则代表已经初始化了，直接进入if语句块
//2、若竞争不严重，counterCells有可能还未初始化，为null，先尝试CAS操作递增baseCount值
if ((as = counterCells) != null ||!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
//进入此语句块有两种可能：
//1.counterCells被初始化完成了，不为null
//2.CAS操作递增baseCount值失败了，说明出现并发冲突,则将计数值累加到Cell槽
CounterCell a;
long v;
int m;
boolean uncontended = true; //标志是否存在竞争
//1.先判断计数桶是否初始化,如果as=null，说明没有，进入语句块
//2.判断计数桶长度是否为空，若是进入语句块
//3.这里做了一个线程变量随机数，若桶的这个位置为空，进入语句块（根据线程hash值计算槽索引）
//4.到这里说明桶已经初始化了，且随机的这个位置不为空，尝试CAS操作使桶加1，失败进入语句块
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(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(); //统计容器大小
}
}
}
- 总结：
- 首先，如果counterCells为null，说明之前一直没有出现过冲突，直接将值累加到baseCount上即可；
- 否则，尝试更新counterCells[i]中的值 ( a = as[ThreadLocalRandom.getProbe() & m]) == null )，更新成功就退出， 如果失败说明槽中也出现了并发冲突，可能涉及槽数组，即counterCells的扩容，所以调用fullAddCount方法。
【注】：由此可见，统计容器大小其实是用了两种思路：
1、CAS方式直接递增：在线程竞争不大的时候，直接使用CAS操作递增baseCount值即可，这里说的竞争不大指的是CAS操作不会失败的情况
2、分而治之桶计数：若出现了CAS操作失败的情况，则证明此时有线程竞争了，计数方式从CAS方式转变为分而治之的桶计数方式
CHM的fullAddCount()源码分析
- 上文说过，当出现了并发冲突，则不会再用CAS方式来计数了，直接使用桶方式，从上面的addCount方法可以看出来，此时的countCell是为空的(或者不为空但CAS更新失败)，最终一定会进入fullAddCount方法来进行初始化桶（这一篇博客对计数这一块更清晰一些）：
private final void fullAddCount(long x, boolean wasUncontended) {
int h;
if ((h = ThreadLocalRandom.getProbe()) == 0) {
ThreadLocalRandom.localInit(); // force initialization
h = ThreadLocalRandom.getProbe();
wasUncontended = true;
}
boolean collide = false; // True if last slot nonempty
for (;;) {
CounterCell[] as; CounterCell a; int n; long v;
...
//如果计数桶!=null，证明已经初始化，此时不走此语句块
if ((as = counterCells) != null && (n = as.length) > 0) {
...
}
//进入此语句块进行计数桶的初始化
//CAS设置cellsBusy=1，表示现在计数桶Busy中...
else if (cellsBusy == 0 && counterCells == as &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
//若有线程同时初始化计数桶，由于CAS操作只有一个线程进入这里
boolean init = false;
try { // Initialize table
//再次确认计数桶为空
if (counterCells == as) {
//初始化一个长度为2的计数桶👌👌
CounterCell[] rs = new CounterCell[2];
//h为一个随机数，与上1则代表结果为0、1中随机的一个
//也就是在0、1下标中随便选一个计数桶，x=1，放入1的值代表增加1个容量
rs[h & 1] = new CounterCell(x);
//将初始化好的计数桶赋值给ConcurrentHashMap
counterCells = rs;
init = true;
}
} finally {
//最后将busy标识设置为0，表示不busy了
cellsBusy = 0;
}
if (init)
break;
}
//若有线程同时来初始化计数桶，则没有抢到busy资格的线程就先来CAS递增baseCount
else if (U.compareAndSwapLong(this, BASECOUNT, v = baseCount, v + x))
break; // Fall back on using base
}
}
- 到这里就完成了计数桶的初始化工作，之后的计数都将会使用计数桶方式来统计总数；💦💦💦
[注]：从上面的分析中我们知道，计数桶初始化的长度为2，在竞争大的时候肯定是不够用的，所以一定有计数桶的扩容操作，所以现在就有两个问题了：- 什么条件下会进行计数桶的扩容？
- 扩容操作是怎么样的？
- 我们做一个假设,如果此时是用计数桶方式进行计数：
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)) {
CounterCell a; long v; int m;
boolean uncontended = true;
//此时显然会在计数桶数组中随机选一个计数桶
//然后使用CAS操作将此计数桶中的value+1
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
//若CAS操作失败，证明有竞争，进入fullAddCount方法
fullAddCount(x, uncontended);
return;
}
if (check <= 1)
return;
s = sumCount();
}
}
- 进入fullAddCount方法：
private final void fullAddCount(long x, boolean wasUncontended) {
int h;
if ((h = ThreadLocalRandom.getProbe()) == 0) {
ThreadLocalRandom.localInit(); // force initialization
h = ThreadLocalRandom.getProbe();
wasUncontended = true;
}
boolean collide = false; // True if last slot nonempty
for (;;) {
CounterCell[] as; CounterCell a; int n; long v;
//计数桶初始化好了，一定是走这个if语句块
if ((as = counterCells) != null && (n = as.length) > 0) {
//从计数桶数组随机选一个计数桶，若为null表示该桶位还没线程递增过
if ((a = as[(n - 1) & h]) == null) {
//查看计数桶busy状态是否被标识
if (cellsBusy == 0) { // Try to attach new Cell
//若不busy，直接new一个计数桶
CounterCell r = new CounterCell(x); // Optimistic create
//CAS操作，标示计数桶busy中
if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
boolean created = false;
try { // Recheck under lock
CounterCell[] rs; int m, j;
//在锁下再检查一次计数桶为null
if ((rs = counterCells) != null &&
(m = rs.length) > 0 &&
rs[j = (m - 1) & h] == null) {
//将刚刚创建的计数桶赋值给对应位置
rs[j] = r;
created = true;
}
} finally {
//标示不busy了
cellsBusy = 0;
}
if (created)
break;
continue; // Slot is now non-empty
}
}
collide = false;
}
else if (!wasUncontended) // CAS already known to fail
wasUncontended = true; // Continue after rehash
//走到这里代表计数桶不为null，尝试递增计数桶
else if (U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))
break;
else if (counterCells != as || n >= NCPU)
collide = false; // At max size or stale
//若CAS操作失败了，到了这里，会先进入一次，然后再走一次刚刚的for循环
//若是第二次for循环，collide=true，则不会走进去
else if (!collide)
collide = true;
//计数桶扩容，一个线程若走了两次for循环，也就是进行了多次CAS操作递增计数桶失败了
//则进行计数桶扩容，CAS标示计数桶busy中
else if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
try {
//确认计数桶还是同一个
if (counterCells == as) {// Expand table unless stale
//将长度扩大到2倍
CounterCell[] rs = new CounterCell[n << 1];
//遍历旧计数桶，将引用直接搬过来
for (int i = 0; i < n; ++i)
rs[i] = as[i];
//赋值
counterCells = rs;
}
} finally {
//取消busy状态
cellsBusy = 0;
}
collide = false;
continue; // Retry with expanded table
}
h = ThreadLocalRandom.advanceProbe(h);
}
else if (cellsBusy == 0 && counterCells == as &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
//初始化计数桶...
}
else if (U.compareAndSwapLong(this, BASECOUNT, v = baseCount, v + x))
break; // Fall back on using base
}
}
- 看到这里我们可以解决那两个问题了：
- 1、什么条件下会进行计数桶的扩容？
答：在CAS操作递增计数桶失败了3次之后，会进行扩容计数桶操作，注意此时同时进行了两次随机定位计数桶来进行CAS递增的，所以此时可以保证大概率是因为计数桶不够用了，才会进行计数桶扩容； - 2、扩容操作是怎么样的？
答：计数桶长度增加到两倍长度，数据直接遍历迁移过来，由于计数桶不像HashMap数据结构那么复杂，有hash算法的影响，加上计数桶只是存放一个long类型的计数值而已（也没有CAS，也可能造成并发问题把），所以直接赋值引用即可；
- 1、什么条件下会进行计数桶的扩容？
【注】：在这里我们再次总结一下计数中的并发技巧：
- 1、利用CAS递增baseCount值来感知是否存在线程竞争，若竞争不大直接CAS递增baseCount值即可，性能与直接baseCount++差别不大；
- 2、若存在线程竞争，则初始化计数桶，若此时初始化计数桶的过程中也存在竞争，多个线程同时初始化计数桶，则没有抢到初始化资格的线程直接尝试CAS递增baseCount值的方式完成计数，最大化利用了线程的并行。此时使用计数桶计数，分而治之的方式来计数，此时两个计数桶最大可提供两个线程同时计数，同时使用CAS操作来感知线程竞争，若两个桶情况下CAS操作还是频繁失败（失败3次），则直接扩容计数桶，变为4个计数桶，支持最大同时4个线程并发计数，以此类推…同时使用位运算和随机数的方式"负载均衡"一样的将线程计数请求接近均匀的落在各个计数桶中。
CHM类的扩容机制💦💦💦💦
CHM类的扩容基本思路
- JDK1.8中，ConcurrentHashMap最复杂的部分就是 扩容、数据迁移， 因为涉及多线程的合作和rehash()；
- 我们先看一下一般的HashMap如何扩容的。
- HashMap的扩容一般包含两个步骤：
- ①、table数组的扩容：
- table数组的扩容，一般就是新建一个2倍大小的槽数组，这个过程通过由一个单线程完成，且不允许出现并发。
- ②、数据迁移：
- 所谓数据迁移，就是把旧table中的各个槽中的结点重新分配到新table中；
- 比如，单线程情况下，可以遍历原来的table，然后put()到新table中；
【注】：这一过程通常涉及到槽中key的rehash()，因为 key映射到桶的位置与table的大小有关，新table的大小变了，key映射的位置一般也会变化，所以我们需要重新计算hash值；
- ①、table数组的扩容：
- ConcurrentHashMap在处理 rehash() 的时候，并不会重新计算每个key的hash值，而是利用了一种很巧妙的方法。
- ConcurrentHashMap内部的table数组的大小必须为2的幂次，这是为什么呢？ 💦💦
- ㈠ 、让key均匀分布，减少冲突； 💦
- ㈡、当table数组的大小为2的幂次时，通过key.hash & table.length-1这种方式计算出的索引i，当table扩容后（2倍），新的索引要么在原来的位置i，要么是i+n。 💦
- 如果索引变为
i+n,那么其变化后的索引最高位一定是1（因为table.length-1的最高位一定是1）。
- 如果索引变为
- 我们通过一个例子说明：
- 扩容前，table数组大小为16，key1和key2映射到同一个索引5；
- 扩容后，table数组的大小变成 2*16=32 ，key1的索引不变，key2的索引变成 5+16=21。
- ConcurrentHashMap内部的table数组的大小必须为2的幂次，这是为什么呢？ 💦💦
- ConcurrentHashMap 在扩容时，这样处理能带来什么好处呢？ 💦💦💦
- 这种处理方式非常利于扩容时多个线程同时进行的数据迁移操作，因为旧table的各个桶中的结点迁移不会互相影响，所以就可以用 “分治” 的方式，将整个table数组划分为很多部分，每一部分包含一定区间的桶，每个数据迁移线程处理各自区间中的结点，对多线程同时进行数据迁移非常有利
- 接下来我们进一步分析ConcurrentHashMap 的扩容机制；
CHM的扩容时机
- 通过前面相关介绍，我们知道，当往table[i]中插入结点时，如果链表的结点数目超过一定阈值（8），就会触发链表 -> 红黑树的转换，这样提高了 查找效率：
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i); // 链表 -> 红黑树 转换
- 接下来我们分析这个 链表 -> 红黑树 的转换操作，treeifyBin(tab, i)：
/*
* 链表 -> 红黑树 转换
*/
private final void treeifyBin(Node<K,V>[] tab, int index) {
Node<K,V> b; int n;
if (tab != null) {
// CASE 1: table的容量 < MIN_TREEIFY_CAPACITY时，直接进行table扩容，不进行红黑树转换，MIN_TREEIFY_CAPACITY默认为64
if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
tryPresize(n << 1);
// CASE 2: table的容量 ≥ MIN_TREEIFY_CAPACITY时，进行相应桶的链表 -> 红黑树的转换
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;
}
// 以TreeBin类型包装，并链接到table[index]中
setTabAt(tab, index, new TreeBin<K,V>(hd));
}
}
}
}
}
- 通过 treeifyBin(Node<K,V>[] tab, int index) 源码可以看出，链表 -> 红黑树这一转换并不是一定会进行的：
- 当桶的容量 < MIN_TREEIFY_CAPACITY(64)，CurrentHashMap 会首先选择扩容（调用 tryPresize() 把数组长度扩大到原来的两倍），而非立即转成红黑树；
- 当桶的容量 >= MIN_TREEIFY_CAPACITY(64)，则选择 链表 -> 红黑树；
- 接下来我们看一下 tryPresize() 如何执行扩容：
/*
* 尝试对table数组进行扩容
* @param 待扩容的大小
*/
private final void tryPresize(int size) { //jdk16
// 视情况将size调整为2的整数次幂，与0.5 * MAXIMUM_CAPACITY来比较 ， tableSizeFor求二次幂
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; //取最大值
if (U.compareAndSetInt(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);
}
} finally {
sizeCtl = sc;
}
}
}
// CASE2: c <= sc说明已经被扩容过了；n >= MAXIMUM_CAPACITY说明table数组已达到最大容量
else if (c <= sc || n >= MAXIMUM_CAPACITY)
break;
// CASE3: 进行table扩容
else if (tab == table) {
int rs = resizeStamp(n);
// 这个CAS操作可以保证，仅有一个线程会执行扩容
if (U.compareAndSetInt(this , SIZECTL , sc , (rs << RESIZE_STAMP_SHIFT) + 2))
transfer(tab, null);
}
}
}
- 前两种情况不讨论了，对于CASE3，jdk16相比jdk1.8已经有了优化，去掉了一个if判断，直接通过CAS和移位运算进行扩容操作，保证了只有一个线程会执行扩容，jdk中if判断是否是单线程，分别进行了transfer(),只不过调用参数不一样，我们通过一张图比较：
【注】：ConcurrentHashMap运用CAS操作，将扩容操作的并发性能实现最大化，在扩容过程中，就算有线程调用get查询方法，也可以安全的查询数据，若有线程进行put操作，还会协助扩容，利用sizeCtl标记位和各种volatile变量进行CAS操作达到多线程之间的通信、协助，在迁移过程中只锁一个Node节点，即保证了线程安全，又提高了并发性能。
CHM的扩容之数据迁移原理💦💦💦
- 通过tryPresize() 我们发现调用了transfer方法，该方法可以被多个线程同时调用，是“数据迁移”的核心操作方法， 接下来我们看一看
/**
* 数据转移和扩容.
* 每个调用tranfer的线程会对当前旧table中[transferIndex-stride, transferIndex-1]位置的结点进行迁移
*
* @param tab 旧table数组
* @param nextTab 新table数组
*/
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
int n = tab.length, stride;
// stride可理解成“步长”，即“数据迁移”时，每个线程要负责旧table中的多少个桶，根据几核的CPU决定“步长”，最少16
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE) //MIN_TRANSFER_STRIDE默认16
stride = MIN_TRANSFER_STRIDE; // subdivide range
if (nextTab == null) { // 第二个参数，nextable为null说明第一次扩容
try {
@SuppressWarnings("unchecked")
// 创建新table数组，扩大一倍,32,n还为16
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // 处理内存溢出（OOME）的情况
sizeCtl = Integer.MAX_VALUE; //将表示容量的sizeCtl 设置为最大值，然后返回
return;
}
nextTable = nextTab; //设置nextTable变量为扩容后的数组
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，并进行本轮扩容的收尾工作
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) {
int nextIndex, nextBound;
if (--i >= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}
else if (U.compareAndSetInt(this, TRANSFERINDEX, nextIndex, nextBound = (nextIndex > stride ?
nextIndex - stride : 0))) {
bound = nextBound;
i = nextIndex - 1;
advance = false;
}
}
// CASE1：当前是处理最后一个tranfer任务的线程或出现扩容冲突
if (i < 0 || i >= n || i + n >= nextn) {
int sc;
if (finishing) { // 所有桶迁移均已完成
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
// 扩容线程数减1,表示当前线程已完成自己的transfer任务
if (U.compareAndSetInt(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
}
}
// CASE2：旧桶本身为null，不用迁移，直接尝试放一个ForwardingNode
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
// CASE3：该旧桶已经迁移完成，直接跳过
else if ((fh = f.hash) == MOVED)
advance = true; // already processed
// CASE4：该旧桶未迁移完成，进行数据迁移
else {
synchronized (f) {
if (tabAt(tab, i) == f) {
Node<K,V> ln, hn;
// CASE4.1：桶的hash>0，说明是链表迁移
if (fh >= 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; // 表示当前旧桶的结点已迁移完毕
}
// CASE4.2：红黑树迁移
else if (f instanceof TreeBin) {
/**
* 下面的过程会先以链表方式遍历，复制所有结点，然后根据高低位组装成两个链表；
* 然后看下是否需要进行红黑树转换，最后放到新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; // 表示当前旧桶的结点已迁移完毕
}
else if (f instanceof ReservationNode) //jdk16特有，1.8没有
throw new IllegalStateException("Recursive update");
}
}
}
}
}
- 这个方法复杂一些，我们把它一步一步分解开来看，后续我会看别的文章继续补充：
①、我们先看 tranfer() 的开头，会计算出一个stride变量的值，这个stride其实就是每个线程处理的桶区间，也就是步长： 💦
// stride可理解成“步长”，即“数据迁移”时，每个线程要负责旧table中的多少个桶，根据CPU决定步长
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE) //MIN_TRANSFER_STRIDE默认16
stride = MIN_TRANSFER_STRIDE; // subdivide range
- 根据是否是多核的CPU确定步长，不过最小步长为16，因为MIN_TRANSFER_STRIDE的默认值为16；
②、接下来就是进行扩容，当首次扩容时，将table数组的容量变成原来的2倍： 💦
if (nextTab == null) { // 第二个参数，即新的table为null说明第一次扩容
try {
@SuppressWarnings("unchecked")
// 创建新table数组，扩大一倍
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // 处理内存溢出（OOME）的情况
sizeCtl = Integer.MAX_VALUE; //将表示容量的sizeCtl 设置为最大值，然后返回
return;
}
nextTable = nextTab; //扩容后的数组nextTable
transferIndex = n; // [transferIndex-stride, transferIndex-1]表示当前线程要进行数据迁移的桶区间
}
int nextn = nextTab.length;
- 注意上面的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，说明原来这个桶就没有数据，那就直接尝试通过CAS操作放置一个ForwardingNode，表示这个桶已经处理完成，CAS设置成功则advance为true，表示该桶已经完成迁移。
// CASE2：旧桶本身为null，不用迁移，直接尝试放一个ForwardingNode
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
【注】：ForwardingNode我们在上一篇提到过，主要做占用，多线程进行数据迁移时，其它线程看到这个桶中是ForwardingNode结点，就知道这一段范围的桶有线程已经在数据迁移了。另外，当最后一个线程完成迁移任务后，会遍历所有桶，看看是否都是ForwardingNode，如果是，那么说明整个扩容/数据迁移的过程就完成了。
④、CASE3 : 桶table[i]不为空，但已经迁移完：
- 桶已经被ForwardingNode结点占用了，表示该桶的数据都迁移完了，当然标志位advance设为true：
// CASE3：该旧桶已经迁移完成，直接跳过
else if ((fh = f.hash) == MOVED)
advance = true; // already processed
⑤、CASE4 : 桶table[i]未迁移完成： 💦
- 如果旧桶的数据未迁移完成，就要进行迁移，这里根据桶中结点的类型分为：链表迁移、红黑树迁移；
⒈、链表迁移： 💦- 链表迁移的过程大致分为2步：
- 首先会遍历一遍原链表，找到最后一个相邻runBit不同的结点（为了充当链表头），runBit是根据key.hash和旧table长度n进行与运算得到的值，由于table的长度为2的幂次，所以runbit只可能为0或最高位为1
- 其次会进行第二次链表遍历，按照第一次遍历找到的结点为界，将原链表分成2个子链表，再链接到新table的槽中。可以看到，新table的索引要么是i，要么是i+n，这里就利用了前文中说的ConcurrentHashMap的rehash特点。
- 链表迁移的过程大致分为2步：
// CASE4.1：桶的hash>0，说明是正常结点，则链表迁移
if (fh >= 0) {
/**
* 下面的过程会将旧桶中的链表分成两部分：ln链和hn链
* ln链会插入到新table的槽i中，hn链会插入到新table的槽i+n中
*/
int runBit = fh & n; // 由于n是2的幂次，所以runBit要么是0，要么高位是1，fh是桶上的哈希值
Node<K,V> lastRun = f; // lastRun指向最后一个相邻runBit不同的结点
for (Node<K,V> p = f.next; p != null; p = p.next) {
int b = p.hash & n; //b要么是0，要么高位是1
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) {
/**
* 下面的过程会先以链表方式遍历，复制所有结点，然后根据高低位组装成两个链表；
* 然后看下是否需要进行红黑树转换，最后放到新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) : //判断门限，如果大于则继续用树，树没改变则直接返回t
(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; // 表示当前旧桶的结点已迁移完毕
}
⑥、CASE5: 当前是最后一个迁移任务或出现扩容冲突：
- 我们刚才说了，调用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); //阈值为newTable的0.75倍
return;
}
// 扩容线程数减1,表示当前线程已完成自己的transfer任务
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
// 判断当前线程是否是本轮扩容中的最后一个线程，如果不是，则直接退出，如果是则设置标志位finishing
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
finishing = advance = true;
/**💙💙💙💙💙💙
* 最后一个数据迁移线程要重新检查一次旧table中的所有桶，看是否都被正确迁移到新table了：
* ①正常情况下，重新检查时，旧table的所有桶都应该是ForwardingNode;
* ②特殊情况下，比如扩容冲突(多个线程申请到了同一个transfer任务)，此时当前线程领取的任务会作废，那么最后检查时，
* 还要处理因为作废而没有被迁移的桶，把它们正确迁移到新table中
*/
i = n; // recheck before commit
}
}
感谢各位的暴击三连哦~
权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区
更多推荐
55
0- 0
已为社区贡献2条内容
所有评论(0)