ConcurrentHashMap面试底层源码解析

本篇文章只需要关注前三个环节的总结就够了，尤其是ConcurrentHashMap面试题部分，已经整理好了

剩下是ConcurrentHashMap 的总结和源码解析是具体的实现

HashMap中的并发问题

• 并发死链（1.7）

​ 在扩容过程中，源码中使用了两个临时变量来对链表进行迁移，e指向链表中第一个元素，next指向链表中的下一个元素，每次迁移都会把e指向的元素，使用头插法迁移到新数组中去，迁移完成后e指向下一个元素，next指向下下个元素

​ 单线程下的扩容

​ 多线程下的扩容

​ 出现死链现象，程序直接卡死，出现 out of memory 错误

• 数据错乱（1.7，1.8）

​ 多线程下同时操作HashMap，调用putVal方法

​ t1线程来了，计算索引，判断该Node节点是否为Null，如果为Null，则执行放入Value的操作，可是还未执行的时候，t2线程来了，判断也为Null放入数据，然后t1线程放入数据，则t2线程数据丢失，产生数据错乱

线程安全集合类

• 遗留的线程安全集合如 Hashtable ， Vector

  在底层的 get 和 put 方法上都加了锁，性能不高

• 使用 Collections 装饰的线程安全集合，如：

  • Collections.synchronizedCollection

  • Collections.synchronizedList

  • Collections.synchronizedMap

  • Collections.synchronizedSet

​ 拿 synchronizedMap 来举例，底层调用的还是以前的map，只不过在调用 get 和 put 方法的时候加了锁，变成了synchronizedMap，典型的装饰者模式

​ 重点介绍 java.util.concurrent.* 下的线程安全集合类，可以发现它们有规律，里面包含三类关键词：

Blocking类、CopyOnWrite类、Concurrent类

• Blocking 大部分实现基于锁，并提供用来阻塞的方法
• CopyOnWrite 之类容器修改开销相对较重
• Concurrent 类型的容器
  • 内部很多操作使用 cas 优化，一般可以提供较高吞吐量
  • 弱一致性
    • 遍历时弱一致性，例如，当利用迭代器遍历时，如果容器发生修改，迭代器仍然可以继续进行遍 历，这时内容是旧的
    • 求大小弱一致性，size 操作未必是 100% 准确
    • 读取弱一致性

遍历时如果发生了修改，对于非安全容器来讲，使用 fail-fast 机制也就是让遍历立刻失败，抛出 ConcurrentModificationException，不再继续遍历

ConcurrentHashMap面试题

1. ConcurrentHashMap1.7 和 1.8 有什么不同？

1. 数据结构

• 1.7：Segment(大数组) + HashEntry(小数组) + 链表

  每个 Segment 对应一把锁，如果多个线程访问不同的 Segment，则不会冲突

  segment 继承了可重入锁（ReentrantLock），调用它的 put 方法，调用tryLock尝试加锁，在尝试期间, 还可以顺便看该节点在链表中有没有, 如果没有顺便创建出来

  用 volatile 修饰了 HashEntry 的数据 value 和 下一个节点 next，保证了多线程环境下数据获取时的可见性！

  Segment[0] 原型：体现了原型模式，首次创建其它小数组时，会以此原型为依据，数组长度，扩容因子都会以原型为准

• 1.8： Node 数组 + 链表或红黑树

  数组的每个头节点作为锁，如果多个线程访问的头节点不同，则不会冲突

  首次生成头节点时如果发生竞争，利用 cas 而非 syncronized，进一步提升性能

2. 主要参数区别

• 1.7：小数组的初始容量 = capacity / clevel，最小是2

• 1.8：capacity 代表预估的元素个数，capacity / factor 来计算出初始数组大小，需要贴近 2ⁿ

  loadFactor 只在计算初始数组大小时被使用，之后扩容固定为 3/4

3. 初始化的时机

1.8 与 1.7 相比是懒惰初始化，调用put时才会初始化

4.并发度

• 1.7：Segment 数组大小即并发度，决定了同一时刻最多能有多少个线程并发访问

  Segment 数组不能扩容，意味着并发度在 ConcurrentHashMap 创建时就固定了

• 1.8：Node 数组有多大，并发度就有多大，与 1.7 不同，Node 数组可以扩容

5. 索引计算

• 1.7 计算主要依托 segmentShift 和 segmentMask 来实现

  假设大数组长度是 2^m，key 在大数组内的索引是 key 的二次 hash 值的高 m 位

  假设小数组长度是 2ⁿ，key 在小数组内的索引是 key 的二次 hash 值的低 n 位

6. 扩容的一些小问题

​ 1.7 每个小数组的扩容相对独立，小数组在超过扩容因子时会触发扩容，每次扩容翻倍

​ **扩容条件：**1.8 Node 数组满 3/4 时就会扩容，1.7超3/4

7. size的计算

size 计算实际发生在 put，remove 改变集合元素的操作之中

1.7

• 计算元素个数前，先不加锁计算两次，如果前后两次结果如一样，认为个数正确返回

• 如果不一样，进行重试，重试次数超过 3，将所有 segment 锁住，重新计算个数返回

1.8

• 没有竞争发生，向 baseCount 累加计数
• 有竞争发生，新建 counterCells，向其中的一个 cell 累加计数
  • counterCells 初始有两个
  • cell 如果计数竞争比较激烈，会创建新的 cell 来累加计数

2. 存放元素的数组是什么类型的？

• JKD8之前是Entry<K,V>类型，JDK8之后是Node<K,V>类型，其实只是换了一个名字，都实现了一样的接口：Map.Entry<K,V>

• 里面存放了hash，key，value，以及next节点。它的value和nextTable等用volatile进行修饰，可以保证多线程之间的可见性。

3. Key、Value是否可为Null？

• HashMap可存在一个为null的key，value值可为null

• Hashtable中如果key为null，则抛出空指针异常

• ConcurrentHashMap不允许空的键值，抛出空指针异常

4. ConcurrentHashMap1.8的put流程

• 首先检查是否有空的键值，否则就抛出空指针异常

• 计算对象的索引值，用到了spread 方法

  spread 方法能确保返回结果是正整数，并会综合高位低位, 具有更好的 hash 性

• 懒惰初始化 table ，因此检查是否有当前桶节点，没有就初始化，使用 cas 来保证并发安全，无需 synchronized 创建成功

• 初始化完成放入元素，根据binCount来判断是否有冲突，链表为1，树为2

  • 如果当前链表为空，就用cas的方式创建链表头节点
  • 如果链表不为空，用 synchronized 锁住链表头节点，添加元素到尾部，或者返回已有元素
  • 最后判断是否需要树化

  如果是树，走树的添加逻辑

• put成功调用addCount方法，增加计数

如果扩容时并发 put

• 如果 put 的线程与扩容线程操作的链表是同一个，put 线程会阻塞
• 如果 put 的线程操作的链表还未迁移完成，即头节点不是 ForwardingNode，则可以并发执行
• 如果 put 的线程操作的链表（如16 - 31）已经迁移完成，即头结点是 ForwardingNode，则可以协助扩容（如1 - 16）

5. ConcurrentHashMap1.8的get流程

ConcurrentHashMap的一大亮点，全程无锁，eh节点值的正负

用了 UNSAFE 方法保证了可见性，而且 Node 的元素 value 和指针 next 是用 volatile 修饰的，在多线程环境下线程A修改节点的 value 或者新增节点的时候是对线程B可见的。

• 计算索引，找到数组位置
• 如果头结点已经是要查找的 key，判断key是否相同，还可以调用equals进行比较
• 头节点(eh) 的 hash 为负数表示该 bin 在扩容中(ForwardingNode)或是 treebin, 这时调用 find 方法来查找，如果是链表遍历比对即可

如果扩容时并发 get

• 根据是否为 ForwardingNode 来决定是在新数组查找还是在旧数组查找，不会阻塞
• 如果链表长度超过 1，则需要对节点进行复制（创建新节点），怕的是节点迁移后 next 指针改变
• 如果链表最后几个元素扩容后索引不变，则节点无需复制

6. ConcurrentHashMap迭代器是强一致性还是弱一致性？HashMap呢？

HashMap强一致性

ConcurrentHashMap弱一致性，可以支持在迭代过程中，向map添加新元素

7. 1.8 中为什么使用内置锁 synchronized替换 可重入锁 ReentrantLock？

• 1.6 之后synchronized 锁的实现引入了大量的优化
• 假设使用可重入锁来获得同步支持，那么每个节点都需要通过继承 AQS 来获得同步支持。但并不是每个节点都需要获得同步支持的，只有链表的头节点（红黑树的根节点）需要同步，这无疑带来了巨大内存浪费

8. ConcurrentHashMap是如何保证线程安全的？

• 1.7 中，ConcurrentHashMap 采用了分段锁策略，将一个 HashMap 切割成 Segment 数组，其中 Segment 可以看成一个 HashMap， 不同点是 Segment 继承自 ReentrantLock，在操作的时候给 Segment 赋予了一个对象锁，从而保证多线程环境下并发操作安全
• 1.8 中，与此对应的 ConcurrentHashMap 也是采用了与 HashMap 类似的存储结构，但是 JDK1.8 中 ConcurrentHashMap 并没有采用分段锁的策略，而是在元素的节点上采用 CAS + synchronized 操作来保证并发的安全性

9. ConcurrentHashMap是如何扩容的？

• transfer方法，以链表为单位从后向前迁移链表，迁移完成的将旧数组头节点替换为 ForwardingNode

• 锁住链表头，链表的搬迁逻辑，树的搬迁逻辑

• 还有扩容时的put问题，get问题

---

ConcurrentHashMap 1.7 总结

• 数据结构：Segment(大数组) + HashEntry(小数组) + 链表

  每个 Segment 对应一把锁，如果多个线程访问不同的 Segment，则不会冲突

• 主要参数
  

  • capacity：与小数组（HashEntry）的容量有关（小数组的初始容量 = capacity / clevel，最小是2）
  • factor：负载因子，影响的是小数组的扩容
  • clevel：并发度，也即Segment 的个数，大数组的个数，默认是16

• 并发度：Segment 数组大小即并发度，决定了同一时刻最多能有多少个线程并发访问。Segment 数组不能扩容，意味着并发度在 ConcurrentHashMap 创建时就固定了

• 索引计算

  • 假设大数组长度是 2^m，key 在大数组内的索引是 key 的二次 hash 值的高 m 位
  • 假设小数组长度是 2ⁿ，key 在小数组内的索引是 key 的二次 hash 值的低 n 位

• 扩容：每个小数组的扩容相对独立，小数组在超过扩容因子时会触发扩容，每次扩容翻倍

• Segment[0] 原型：体现了原型模式，首次创建其它小数组时，会以此原型为依据，数组长度，扩容因子都会以原型为准

ConcurrentHashMap 1.8 总结

• 数据结构：Node 数组 + 链表或红黑树，数组的每个头节点作为锁，如果多个线程访问的头节点不同，则不会冲突。首次生成头节点时如果发生竞争，利用 cas 而非 syncronized，进一步提升性能

• 并发度：Node 数组有多大，并发度就有多大，与 1.7 不同，Node 数组可以扩容

• **初始化的时机：**与 1.7 相比是懒惰初始化，调用put时才会初始化

• **扩容条件：**Node 数组满 3/4 时就会扩容

• 构造参数：

  • capacity 代表预估的元素个数，capacity / factor 来计算出初始数组大小，需要贴近 2ⁿ
  • loadFactor 只在计算初始数组大小时被使用，之后扩容固定为 3/4

• **扩容单位：**以链表为单位从后向前迁移链表，迁移完成的将旧数组头节点替换为 ForwardingNode
  

• 扩容时并发 get

  • 根据是否为 ForwardingNode 来决定是在新数组查找还是在旧数组查找，不会阻塞
  • 如果链表长度超过 1，则需要对节点进行复制（创建新节点），怕的是节点迁移后 next 指针改变
  • 如果链表最后几个元素扩容后索引不变，则节点无需复制

• 扩容时并发 put

  • 如果 put 的线程与扩容线程操作的链表是同一个，put 线程会阻塞
  • 如果 put 的线程操作的链表还未迁移完成，即头节点不是 ForwardingNode，则可以并发执行
  • 如果 put 的线程操作的链表（如16 - 31）已经迁移完成，即头结点是 ForwardingNode，则可以协助扩容（如1 - 16）

• 超过树化阈值时的扩容问题，如果容量已经是 64，直接树化，否则在原来容量基础上做 3 轮扩容

ConcurrentHashMap 1.8 源码解析

重要属性和内部类

• Node 实现了实现了Map.Entry接口
• sizeCtl为 -1 表示初始化，扩容时也为负
• Node，nextTable等用volatile修饰

// 默认为 0
// 当初始化时, 为 -1
// 当扩容时, 为 -(1 + 扩容线程数)
// 当初始化或扩容完成后，为 下一次的扩容的阈值大小
private transient volatile int sizeCtl;

// 整个 ConcurrentHashMap 就是一个 Node[]
static class Node<K,V> implements Map.Entry<K,V> {} //实现了Map.Entry接口

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

// 扩容时的 新 hash 表
private transient volatile Node<K,V>[] nextTable;

/*  注意以上几个变量都使用了volatile，因此也都会采用CAS来保证线程安全
	接下来看几个重要的内部类
*/ 
// 扩容时如果某个 bin 迁移完毕, 用 ForwardingNode 作为旧 table bin 的头结点
static final class ForwardingNode<K,V> extends Node<K,V> {}

// 用在 compute 以及 computeIfAbsent 时, 用来占位, 计算完成后替换为普通 Node
static final class ReservationNode<K,V> extends Node<K,V> {}

// 作为 treebin 的头节点, 存储 root 和 first
static final class TreeBin<K,V> extends Node<K,V> {}

// 作为 treebin 的节点, 存储 parent, left, right
static final class TreeNode<K,V> extends Node<K,V> {}

重要方法

// 获取 Node[] 中第 i 个 Node
static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i)
 
// cas 修改 Node[] 中第 i 个 Node 的值, c 为旧值, v 为新值
static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i, Node<K,V> c, Node<K,V> v)
 
// 直接修改 Node[] 中第 i 个 Node 的值, v 为新值
static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v)

构造方法

实现了懒惰初始化，在构造方法中仅仅计算了 table 的大小，以后在第一次使用时才会真正创建

//初始容量，负载因子，并发度
public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
     if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
     	throw new IllegalArgumentException();
    //保证初始容量大小和并发度相等
     if (initialCapacity < concurrencyLevel) 
     	initialCapacity = concurrencyLevel;  
    //这也是和普通Hashmap不同的点
     long size = (long)(1.0 + (long)initialCapacity / loadFactor);
     // tableSizeFor 仍然是保证计算的大小是 2^n, 即 16,32,64 ... 
     int cap = (size >= (long)MAXIMUM_CAPACITY) ?
     	MAXIMUM_CAPACITY : tableSizeFor((int)size);
     this.sizeCtl = cap;
}

get流程

• spread 方法能确保返回结果是正整数，也会综合高位低位, 具有更好的 hash 性

ConcurrentHashMap的一大亮点，全程无锁，eh节点值的正负

public V get(Object key) {
     Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
     // spread 方法能确保返回结果是正整数(负数都有别的含义)
     int h = spread(key.hashCode());
     if ((tab = table) != null && (n = tab.length) > 0 &&
     	(e = tabAt(tab, (n - 1) & h)) != null) {
         // 如果头结点已经是要查找的 key，判断key是否相同，还可以调用equals进行比较
         if ((eh = e.hash) == h) {
             if ((ek = e.key) == key || (ek != null && key.equals(ek)))
             	return e.val;
         }
         //头节点(eh) 的 hash 为负数表示该 bin 在扩容中(ForwardingNode)或是 treebin, 这时调用 find 方法来查找
         else if (eh < 0)
         	return (p = e.find(h, key)) != null ? p.val : null;
         // 正常遍历链表, 用 equals 比较
         while ((e = e.next) != null) {
             if (e.hash == h &&
             	((ek = e.key) == key || (ek != null && key.equals(ek))))
             	return e.val;
         }
     }
     return null;
}

put流程

以下数组简称（table），链表简称（bin）

public V put(K key, V value) {
	return putVal(key, value, false);
}
final V putVal(K key, V value, boolean onlyIfAbsent) {
     //ConcurrentHashMap不允许空的键值
     if (key == null || value == null) throw new NullPointerException();
     // 其中 spread 方法会综合高位低位, 具有更好的 hash 性，这一点也很重要
     int hash = spread(key.hashCode());
     int binCount = 0;
    //这是一个死循环
     for (Node<K,V>[] tab = table;;) {
     // f 是链表头节点
     // fh 是链表头结点的 hash
     // i 是链表在 table 中的下标
     	Node<K,V> f; int n, i, fh;
     // 没有就要创建 table
     	if (tab == null || (n = tab.length) == 0)
     		tab = initTable();// 初始化 table 使用了 cas, 无需 synchronized 创建成功, 进入下一轮循环
 		// 要创建链表头节点
         else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
         // 添加链表头使用了 cas, 无需 synchronized
             if (casTabAt(tab, i, null,
             	new Node<K,V>(hash, key, value, null)))
             break;
         }
          // 帮忙扩容
         else if ((fh = f.hash) == MOVED)
         // 锁住链表帮忙扩容，帮忙之后, 进入下一轮循环
         	tab = helpTransfer(tab, f);
         //进到这里说明桶下标冲突了
         else {
             V oldVal = null;
             // 开始加锁，锁住链表头节点
             synchronized (f) {
             // 再次确认链表头节点没有被移动
             if (tabAt(tab, i) == f) {
             	// 链表
             	if (fh >= 0) {
                    //说明该链表有冲突，链表为1，树为2
             		binCount = 1;
             		// 遍历链表
            		for (Node<K,V> e = f;; ++binCount) {
             			K ek;
            			// 找到相同的 key
            			if (e.hash == hash &&
             				((ek = e.key) == key ||
             				(ek != null && key.equals(ek)))) {
                            oldVal = e.val;
             				// 更新
            				if (!onlyIfAbsent)
             					e.val = value;
             					break;
                        }
             				Node<K,V> pred = e;
             				// 已经是最后的节点了, 新增 Node, 追加至链表尾
                    		if ((e = e.next) == null) {
                     			pred.next = new Node<K,V>(hash, key,
                     										value, null);
                     			break;
                            }
                    }
                }
             	// 红黑树
			 	else if (f instanceof TreeBin) {
 					Node<K,V> p;
 					binCount = 2;
 					// putTreeVal 会看 key 是否已经在树中, 是, 则返回对应的 TreeNode
 					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), 进行链表转为红黑树
 					treeifyBin(tab, i);
 					if (oldVal != null)
 						return oldVal;
 						break;
             }
         }
 	}
    // put成功，增加 size 计数
 	addCount(1L, binCount);
	return null;
}        

具体的 initTable 方法

size的计算流程

size 计算实际发生在 put，remove 改变集合元素的操作之中

• 没有竞争发生，向 baseCount 累加计数
• 有竞争发生，新建 counterCells，向其中的一个 cell 累加计数
  • counterCells 初始有两个
  • cell 如果计数竞争比较激烈，会创建新的 cell 来累加计数
    

transfer 扩容流程

Java 8 数组（Node） +（ 链表 Node | 红黑树 TreeNode ） 以下数组简称（table），链表简称（bin）

• 初始化，使用 cas 来保证并发安全，懒惰初始化 table
• 树化，当 table.length < 64 时，先尝试扩容，超过 64 时，并且 bin.length > 8 时，会将链表树化，树化过程 会用 synchronized 锁住链表头
• put，如果该 bin 尚未创建，只需要使用 cas 创建 bin；如果已经有了，锁住链表头进行后续 put 操作，元素 添加至 bin 的尾部
• get，无锁操作仅需要保证可见性，扩容过程中 get 操作拿到的是 ForwardingNode 它会让 get 操作在新 table 进行搜索
• 扩容，扩容时以 bin 为单位进行，需要对 bin 进行 synchronized，但这时妙的是其它竞争线程也不是无事可 做，它们会帮助把其它 bin 进行扩容，扩容时平均只有 1/6 的节点会把复制到新 table 中
• size，元素个数保存在 baseCount 中，并发时的个数变动保存在 CounterCell[] 当中。最后统计数量时累加 即可

ConcurrentHashMap 1.7 解析

构造器分析

它维护了一个 segment 数组，每个 segment 对应一把锁

• 优点：如果多个线程访问不同的 segment，实际是没有冲突的，这与 jdk8 中是类似的
• 缺点：Segments 数组默认大小为16，这个容量初始化指定后就不能改变了，并且不是懒惰初始化
• 每一个 segment数组对应多个 HashEntry 小数组

采用了 this.segmentShift 和 this.segmentMask ，将 key 的 hash 结果匹配到哪个 segment

• 例如，根据某一 hash 值求 segment 位置，先将高位向低位移动 this.segmentShift 位，结果再与 this.segmentMask 做位于运算，最后得到 segment的位置

put流程

segment 继承了可重入锁（ReentrantLock），调用它的 put 方法

用 volatile 修饰了 HashEntry 的数据 value 和 下一个节点 next，保证了多线程环境下数据获取时的可见性！

• 调用tryLock尝试加锁，在尝试期间, 还可以顺便看该节点在链表中有没有, 如果没有顺便创建出来

• 执行put操作

rehash （扩容）流程

发生在 put 中，因为此时已经获得了锁，因此 rehash 时不需要考虑线程安全

• 扩容流程

get 流程

get 时并未加锁，用了 UNSAFE 方法保证了可见性，扩容过程中，get 先发生就从旧表取内容，get 后发生就从新表取内容

size 计算流程

• 计算元素个数前，先不加锁计算两次，如果前后两次结果如一样，认为个数正确返回

• 如果不一样，进行重试，重试次数超过 3，将所有 segment 锁住，重新计算个数返回

k 做位于运算，最后得到 segment的位置

put流程

[外链图片转存中…(img-LjocRwtw-1641628793256)]

segment 继承了可重入锁（ReentrantLock），调用它的 put 方法

用 volatile 修饰了 HashEntry 的数据 value 和 下一个节点 next，保证了多线程环境下数据获取时的可见性！

• 调用tryLock尝试加锁，在尝试期间, 还可以顺便看该节点在链表中有没有, 如果没有顺便创建出来

• 执行put操作

rehash （扩容）流程

发生在 put 中，因为此时已经获得了锁，因此 rehash 时不需要考虑线程安全

• 扩容流程

get 流程

get 时并未加锁，用了 UNSAFE 方法保证了可见性，扩容过程中，get 先发生就从旧表取内容，get 后发生就从新表取内容

size 计算流程

• 计算元素个数前，先不加锁计算两次，如果前后两次结果如一样，认为个数正确返回

• 如果不一样，进行重试，重试次数超过 3，将所有 segment 锁住，重新计算个数返回