ConcurrentHashMap.put
以下为JDK11 源码
基础概念
- Java Map结构原理
- 为什么 hash表的长度必须为2的N（整数）次幂？
因为 2的N次幂减一的二进制位全部为1 是完美的低位掩码。与key的hash值做与运算可以高效的生成hash表的下标 - 讲讲武德，我们先看下构造器
构造器支持三个参数分控制，value初始数量，扩容阈值系数，预计并发数，三个参数代入公式，算出散列表长度，即结束。并没有立刻初始化散列表/** * 我们只看参数最多的那个构造器 * * @param initialCapacity 预计有多少value * @param loadFactor 扩容阈值系数，直译是负载系数，浮点型小数。在ConcurrentHashMap 中只起到了空置初始容量的作用，与后续扩容无关，后续容量达到sizeCtl 就扩容 sizeCtl 在扩容后会在transfer 方法中重新设置为 (n << 1) - (n >>> 1) * @param concurrencyLevel 预计的并发线程数 */ public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) { if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0) // 简单的逻辑检查 throw new IllegalArgumentException(); if (initialCapacity < concurrencyLevel) // 如果并发度大于容量 initialCapacity = concurrencyLevel; // 就让初始容量等于并发度。以降低竞争。为什么这样可以降低竞争？因为。。。。下面就知道了 // 避免一上来就扩容，放大 一下size 到刚好装得下initialCapacity个value还不会扩容的程度 long size = (long)(1.0 + (long)initialCapacity / loadFactor); // 让size不超过数组最大长度 的 2的N次幂的数值 int cap = (size >= (long)MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : tableSizeFor((int)size); this.sizeCtl = cap; }- 特别说一下 tableSizeFor 方法，JDK11重写了此方法，比JDK8的代码更加巧妙轻清爽
这个重构过程告诉了我们两件事情 1. 动手之前多思考、2. 可读性和效率是可以共存的// JDK11版本。很巧妙的获取大>=C的最小的 2的N次幂 private static final int tableSizeFor(int c) { int n = -1 >>> Integer.numberOfLeadingZeros(c - 1); return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; } /** * 可以对比一下JDK8的版本。JDK11的代码清爽了太多 * Returns a power of two table size for the given desired capacity. * See Hackers Delight, sec 3.2 */ private static final int tableSizeFor(int c) { int n = c - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }
put 方法
开始重点前先大概讲一下脉络
- 加工hash其低16位与高十六位做异或运算，提高低位丰富性，获得新的hash值
- 通过新hash值获得key对应的散列表小标i = (n(数组长度) - 1) & hash)
- 一些检查如初始化、扩容检查等
- 锁定对应节点。这里也是决定ConcurrentHashMap 并发性能的关键因素— 降低锁粒度到 节点
- 记录value数量以及扩容检查，红黑树转换等
同时延伸了一些问题
- 大家想一想ConcurrentHashMap为什么不允许 key 和 value为空？
- 为什么会抛出 Recursive update 异常？
答案写在注释里
/** Implementation for put and putIfAbsent */
final V putVal(K key, V value, boolean onlyIfAbsent) {
// 参数检查 key和value都不允许为空
// 大家想一想为什么不允许value为空？ 据开发者自己回答，为了避免二义性：
// 在map容器里面，调用map.get(key)方法得到的值是null，
// 那你无法判断这个key是在map里面没有映射过，还是这个key在map里面根本就不存在。
// 这种情况下，在非并发安全的map中，你可以通过map.contains(key)的方法来判断。但是在考虑并
// 安全的map中，在两次调用的过程中，这个值是有可能被改变的。
// 引用：https://segmentfault.com/a/1190000021105716
if (key == null || value == null) throw new NullPointerException();
/**
* 加工hash值 spread 函数分两步加工hash值
* 1. 低16位与高十六位做异或运算，提高低位丰富性。（据统计这样可以降低hash碰撞）
* 2. 与HASH_BITS（二进制31位1，int的值最大值）做与运算，得到一个不超过int类型最大值的新hash值
* int spread(int h) {
* return (h ^ (h >>> 16)) & HASH_BITS;
* }
**/
int hash = spread(key.hashCode());
// 碰撞次数，红黑树固定为2
int binCount = 0;
// ConcurrentHashMap 大量应用了CAS 和 volatile 关键字
// 众所周知，解决并发问题离不开CAS + volatile，CAS 离不开自旋
// 所以下面将进入一个 （并发竞争失败 -> 重试，无并发|竞争成功 -> 退出循环）的类似自旋锁的循环
for (Node<K,V>[] tab = table;;) {
// f = 存储value的节点，n = 散列表长度，i = key在散列表下标，fh = f最新的hash值，fk fv = f得键和值
// i 的计算过程原理在开头说过了 i = (n(数组长度) - 1) & hash)
// fh 的hash值(node 的hash值在特殊情况用来做信号量 标记状态 - 如扩容中)
Node<K,V> f; int n, i, fh; K fk; V fv;
if (tab == null || (n = tab.length) == 0)
// 初始化散列表
tab = initTable();
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
// CAS 初始化 Node 成功跳出循环
if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))
break; // no lock when adding to empty bin
}
else if ((fh = f.hash) == MOVED)
// 转发标记，当table正在进行扩容，且f节点已经扩容完成，会标记旧table的i节点的hash值为MOVED, 告诉后面的线程去帮助扩容，或者直接去获取新节点，然后该干嘛干嘛去。
// helpTransfer的具体代码这次就不扩散了 helpTransfer主要做了两个事情
// 1. 扩容已经完成，返回新的 table
// 2. 扩容未完成
// 2.1 满足协助扩容条件（检查扩容状态为进行中&&协助扩容线程没有超过最大线程数），去协助扩容其他Node
// 2.2 不满足协助扩容条件，返回新的nextTable(扩容中的, 虽然在扩容中但是当前节点已经扩容完成。不影响当前操作)
tab = helpTransfer(tab, f);
else if (onlyIfAbsent // check first node without acquiring lock
&& fh == hash
&& ((fk = f.key) == key || (fk != null && key.equals(fk)))
&& (fv = f.val) != null)
// onlyIfAbsent 参数为比较更新方法提供底层支持，如 putIfAbsent computeIfAbsent 等
// key已存在 返回旧 value
return fv;
else {
// 进入正题
V oldVal = null;
// 锁住对应节点。这里也是决定ConcurrentHashMap 并发性能的关键因素--- 降低锁粒度到 节点
synchronized (f) {
// 用cas获取节点检查当前节点是否产生变化，主要避免扩容
if (tabAt(tab, i) == f) {
// 红黑树的hash值是负数
if (fh >= 0) {
binCount = 1;
for (Node<K,V> e = f;; ++binCount) {
// binCount 这时用来表示Node链表长度
// 和hashmap一样这里也用链表来解决轻度冲突
K ek;
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
// 可以替换则替换为新值，否则结束循环 返回 oldVal
e.val = value;
break;
}
Node<K,V> pred = e;
if ((e = e.next) == null) {
pred.next = new Node<K,V>(hash, key, value);
break;
}
}
}
else if (f instanceof TreeBin) {
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;
}
}
else if (f instanceof ReservationNode)
// ReservationNode 是 computeIfAbsent 方法在Node为空的时候生成的用来加锁的占位符
// computeIfAbsent 操作完成的时候会替换为常规的的Node. 这里为什么要抛出异常而不是continue;重新尝试 put操作呢？
// 因为这里的意思是
// 1. 有线程正在执行 computeIfAbsent
// 2. 并且并且在当前线程获取到f，到，当前线程拿到f锁之间
// computeIfAbsent线程完成了 put操作 并释放了f节点的锁
// 那么 这个时候重新走put流程的话，当前线程无法知道自己的key与computeIfAbsent 的key 是否冲突。如果继续循环的话可能盖掉computeIfAbsent的执行结果，那么上层应用可能出现computeIfAbsent不准确的表象，产生底层不可控的业务错误。
// 所以这里只好抛出异常
// but 我感觉程序不可能走到这个位置。
// 因为 computeIfAbsent线程已经在synchronized作用域内设置了i为正常Node
// 当前线程在 第一个判断 （if (tabAt(tab, i) == f) ） 处，不可能得到一个
// （ReservationNode对象）==（ReservationNode对象） 的结果。这点我有点诧异
throw new IllegalStateException("Recursive update");
}
}
if (binCount != 0) {
if (binCount >= TREEIFY_THRESHOLD)
// 遇到冲突 切冲突数量大于8（TREEIFY_THRESHOLD）
// treeifyBin 做了几个事情 大体和 HashMap 差不多
// 1. 散列表长度小于 64 对散列表进行扩容
// 2. 否则 Node 转为红黑树
// treeifyBin 方法比较简单不做扩散
treeifyBin(tab, i);
if (oldVal != null)
// 旧值不为空返回旧值
return oldVal;
break;
}
}
}
// addCount 也先不做扩散，里面负责记录value数量，同时超过阈值的话将触发扩容
addCount(1L, binCount);
return null;
}
3084
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
