ConcurrentHashMap（并发哈希映射）

热身 · 一 保证边界 · 二 原子方法 · 三 仍需自理 · 四 JDK 7 与 8 · 五 put（写入方法） 与扩容 · 六 null（空值） 与 size（数量方法） · 七 检验 · 八 讲出来 · 九 追问 · 十 隔日复测

学完这一课，你能做到

拿到一段用 ConcurrentHashMap（并发哈希映射） 的并发代码，能指出“每一步都线程安全，合起来却出错”的位置，用一次原子方法改对；并能脱稿讲清 JDK 7 与 JDK 8 的实现差别和 put（写入方法） 流程。

和前几课的联系： i++ 丢更新是第3课的内容，桶锁用的是第4课的 synchronized（内置同步关键字），前面线程池里多个任务同时改一张表，就是本课的场景。

主读： Java 21 ConcurrentHashMap（并发哈希映射） 官方文档。读开头的类说明，再查 merge（原子合并方法）、computeIfAbsent（缺失时计算的方法）、mappingCount（映射数量方法） 三个方法。第四、五节讲内部实现，以源码里的实现注释为准。

热身：先回忆前几课（3 分钟）

先凭记忆回答，再展开核对。答不上来就记一句，接着往下学，这不是进入新课的门槛。

一、它保证什么：单次调用是原子的

ConcurrentHashMap（并发哈希映射） 是线程安全的，用它写的统计代码在多线程下一定对吗？

场景：系统按部门统计已完成的审批数。key（键） 是部门编号，value（值） 是数量。每完成一项审批，就执行下面两行。

Integer old = counts.get("dept-A");   // 读
counts.put("dept-A", old + 1);        // 写

验证：示例程序让两个线程都先读完再写，在 JDK 17／21 上稳定输出“分步更新=1”（从 0 开始，应为 2）。

部门A 现在是 5。线程A 和线程B 各完成一项审批，各执行一次这两行。正确结果是 7。但下面这种顺序完全可能发生：

每一步单独看都没错：get（读取方法） 确实读到了 5，put（写入方法） 确实写进了 6。ConcurrentHashMap（并发哈希映射） 保证的是 每一次方法调用 完整地执行，多个线程同时调用也不会把表弄坏。它管不到两次调用之间的空隙。

“读、加一、写回”在业务上是一件事，在代码里却是两次调用。这种由几步拼成的操作叫 composite operation（组合操作）。两次修改只留下一次效果，叫 lost update（更新丢失）。这和热身里的 count++ 是同一个问题。

给 value（值） 加 volatile（可见性关键字） 解决不了，原因和第3课一样：volatile（可见性关键字） 只管可见，不管合并步骤。用 synchronized（内置同步关键字） 把两行包起来能算对，但前提是所有修改这张表的地方都用同一把锁；而且这样一来所有更新都要排队，ConcurrentHashMap（并发哈希映射） 的并发能力就用不上了。所以更好的办法是用它自带的原子方法[JG]，见下一节。

二、怎么改：四个原子方法

这段统计应该怎么改？ConcurrentHashMap（并发哈希映射） 还提供了哪些类似的方法？

计数的意思是“这个部门再加 1”，并不需要先把旧值取出来。把两行换成一次 merge（原子合并方法） 调用就行：

counts.merge("dept-A", 1, Integer::sum);

验证：没有 dept-A 时调用一次，结果为 1；原值为 5 时调用一次，结果为 6。示例程序中两线程各调用一次，从 0 稳定得到 2。

merge（原子合并方法） 有三个参数：要改哪个 key（键）；本次的增量 1；以及旧值和增量怎么合并。Integer::sum 是方法引用，等价于 (oldCount, added) -> oldCount + added。表里还没有这个 key（键） 时，merge（原子合并方法） 直接放入 1；已经有值时，就用这个函数算出新值再写回。读旧值、计算、写新值都在这一次调用里完成，对同一个 key（键），另一个线程插不进来[2]。

同一类方法一共有四个，区别在于“什么时候算”和“返回什么”：

putIfAbsent（不存在才放入的方法） 和 computeIfAbsent（缺失时计算的方法） 的区别 在于值什么时候造出来。putIfAbsent（不存在才放入的方法） 的值要先造好再传进去，即使最后没放入，造值的开销也已经花掉了。computeIfAbsent（缺失时计算的方法） 只在 key（键） 不存在时才执行函数，所以造值成本高时（新建列表、加载配置）选它。

computeIfAbsent（缺失时计算的方法） 的“只算一次”只限一次调用： key（键） 不存在时函数恰好执行一次，已存在时一次也不执行[2]。函数返回 null（空值） 或抛出异常，这次就不建立记录，下一次调用还会再算；记录后来被删掉，也会重新算。顺带记住：函数算出 null（空值） 时，computeIfAbsent（缺失时计算的方法） 不放入，compute（原子重算方法） 和 merge（原子合并方法） 会把这个 key（键） 删掉。

传进去的函数要短。 官方文档写明，函数执行期间，其他线程对这张表的一些更新可能会被阻塞，所以计算应当“short and simple”；函数里也不能再修改这张表[2]。不要在函数里调用短信、支付这类远程接口：一是慢，会让别的更新跟着等；二是短信一旦发出，后面即使出错也撤不回来。

三、原子方法之外，还要自己管什么

用了 ConcurrentHashMap（并发哈希映射），也用了原子方法，是不是就不用再考虑并发问题了？

不是。它只保证 单个 key（键） 的单次操作 是原子的。超出这个范围的事，它都不管。常见的有四种：

可见性方面，它提供了一个保证：一个线程先把对象准备好再 put（写入方法） 进去，另一个线程 get（读取方法） 到这个对象后，能看到 put（写入方法） 之前的准备结果。这是 put（写入方法） 与读到这个值的 get（读取方法） 之间的 happens-before（先行发生关系）[1]。但对象放进表以后，如果再修改它的普通字段，这个保证就不覆盖了。

四、内部实现：从 JDK 7 分段锁到 JDK 8 桶锁

ConcurrentHashMap（并发哈希映射） 是怎么保证线程安全的？JDK 7 和 JDK 8 有什么不同？

先看最早的 Hashtable（旧式同步哈希表）。它的方法基本都用 synchronized（内置同步关键字） 修饰，整张表只有一把锁。一个线程在 put（写入方法） 时，其他线程连 get（读取方法） 都得等[JG]。

JDK 7 的做法是把一张大表切成若干段，每段叫一个 Segment（分段锁），每段配一把锁。Segment（分段锁） 继承了 ReentrantLock（可重入锁），段内是数组加链表。修改数据前先锁住所在的段，写不同段的线程互不影响。段数在创建时就固定了，默认 16，所以写并发度最多大约是 16[JG]。

JDK 8 以后 去掉了分段，结构和 HashMap（普通哈希映射） 一样：一个数组，每个位置是一个 bin（桶），桶里是链表，链表太长时转成 red-black tree（红黑树）。并发控制分三种情况[5]：

• 往空桶放第一个节点： 用 CAS（比较并交换） 直接放入，不加锁。官方注释说这是 put（写入方法） 最常见的情况。
• 桶里已经有节点： 用 synchronized（内置同步关键字） 锁住这个桶的 第一个节点 ，只锁这一个桶。锁住后还要再确认它仍是第一个节点，不是就重试。
• 读： get（读取方法） 不加锁，靠 volatile（可见性关键字） 读拿到最新的节点。

锁的范围从“一段”缩小到“一个桶”，不同桶上的更新通常可以同时进行。但两个不同的 key（键） 如果落在同一个桶里，还是会互相等待。官方注释承认这是按桶加锁的缺点：比如 equals 或传入的函数很慢时，同桶的其他更新会被拖住；不过哈希分布随机时，这种情况不常见[5]。

为什么用 synchronized（内置同步关键字） 而不是 ReentrantLock（可重入锁）？ 官方注释给出的理由是：不想为每个桶单独配一个锁对象，那样太占内存，所以直接拿桶的第一个节点当锁[5]。热身里说过，synchronized（内置同步关键字） 可以锁任意对象，正好满足这个需求。另外，JDK 6 以后 synchronized（内置同步关键字） 做了大量优化，性能已经不是问题[JG]。

Java 21 的源码里还能看到一个 Segment（分段锁） 类，但它只在序列化时用到，是为了兼容旧版本。构造方法里的 concurrencyLevel 参数也只是保留下来，不再决定锁的数量[5]。

五、put（写入方法） 流程、get（读取方法） 与扩容

说一下 ConcurrentHashMap（并发哈希映射） 的 put（写入方法） 流程。get（读取方法） 和扩容呢？

下面按 Java 21 源码里的 putVal 方法，从上到下讲一遍[6]：

1. 检查 null（空值）。 key（键） 或 value（值） 是 null（空值），直接抛 NullPointerException。

2. 计算 hash（哈希）。 用 spread 把 hashCode 的高位也混进来，再算出数组下标。

3. 进入循环。 每种情况处理失败就回到循环开头重试：

   • 数组还没创建：先建数组。数组是第一次插入时才创建的。
   • 目标桶是空的：用 CAS（比较并交换） 放入新节点。成功就结束；失败说明被别的线程抢先了，回到循环开头。
   • 桶头是 forwarding node（转发节点）：说明正在扩容，先帮忙迁移，再到新数组上重试。
   • 其他情况：synchronized（内置同步关键字） 锁住桶头节点，再确认它仍是桶头。如果是链表，就逐个比较：先比 hash（哈希），hash（哈希） 相同再用 equals（相等比较方法）比较 key（键）。两者都相同才是同一个 key（键），这时替换 value（值）；比到链尾都没有相同的，就接到链尾。只比 hashCode（哈希码）不够，因为不同的 key（键） 可能算出相同的 hashCode，这就是 hash collision（哈希冲突）。如果是红黑树，就按树的方式插入。

4. 检查是否转红黑树。 链表长度达到 8 时调用 treeifyBin。但如果数组长度还不到 64，会先扩容，而不是转树。

5. 计数加一。 调用 addCount，同时检查是否需要扩容。

// 简化自 Java 21 putVal，省略了部分分支
if (key == null || value == null) throw new NullPointerException();
int hash = spread(key.hashCode());
for (Node[] tab = table;;) {
    if (tab == null)                    tab = initTable();
    else if (桶 i 为空) {
        if (casTabAt(tab, i, null, 新节点)) break;   // 空桶：CAS，不加锁
    }
    else if (桶头.hash == MOVED)        tab = helpTransfer(tab, 桶头);  // 正在扩容：先帮忙
    else synchronized (桶头) { /* 链表：hash 相同且 equals 才算同一个 key，替换；否则接到链尾。红黑树：按树插入 */ }
}
addCount(1L, binCount);                 // 计数 + 检查扩容

验证：逐行对照本机 JDK 21 源码摘录末尾的 putVal 原文。中文部分是说明，不能编译。

为什么是 8 才转树？ 官方注释给了一张概率表：哈希分布随机时，一个桶里有 8 个节点的概率大约只有一亿分之六。所以链表长到 8，多半说明哈希分布有问题，这时才用红黑树兜底[5]。记住“正常情况几乎碰不到，这是兜底手段”就够了，不用背概率值。

get（读取方法） 不加锁：先定位到桶，比较桶头；桶头是特殊节点（转发节点或红黑树桶）时，交给它自己去查找；否则沿着链表往下找。读数组时用的是 volatile（可见性关键字） 读[5]。

扩容（resize（扩容）） ：元素数超过容量的 0.75 倍时，数组扩成原来的两倍。其他线程发现正在扩容时，会领取一段桶来帮忙迁移，不是干等着。一个桶迁移完后，旧位置会放一个 forwarding node（转发节点）。读写线程遇到它，就转到新数组继续操作。所以扩容进行到一半时照样能读：没迁移的桶在旧数组里读，已迁移的桶跟着转发节点去新数组读[5]。

六、两个细节：为什么不许 null（空值），size（数量方法） 准不准

HashMap（普通哈希映射） 允许 null（空值），ConcurrentHashMap（并发哈希映射） 为什么不允许？它的 size（数量方法） 准确吗？

不许 null（空值）：避免歧义

如果允许 null（空值），get（读取方法） 返回 null（空值） 时含义就不明确：可能是没有这个 key（键），也可能是这个 key（键） 的值本来就是 null（空值）。用 HashMap（普通哈希映射） 时，单线程下可以再调一次 containsKey 来区分。但在并发环境下，两次调用之间别的线程可能已经改了表，containsKey 的结果对不上刚才那次 get（读取方法）。

ConcurrentHashMap（并发哈希映射） 的作者 Doug Lea 的原话是：在非并发的 Map（映射） 里勉强能忍受的歧义，在并发的 Map（映射） 里无法接受[JG]。所以干脆禁止 null（空值）。这样 get（读取方法） 返回 null（空值） 只有一种含义：没有这个 key（键）。如果业务上确实需要表示“空”，可以定义一个专门的空对象来占位，例如 static final Object NONE = new Object();。

size（数量方法）：分散计数，并发时是估计值

如果只用一个变量计数，所有线程每次插入都去改它，这个变量就会成为争抢的热点。所以它的计数分成两部分：一个基础计数 baseCount，加一组 CounterCell（计数单元）。没人争抢时，用 CAS（比较并交换） 修改 baseCount；CAS（比较并交换） 失败说明有竞争，线程就改到不同的格子里，互不干扰。官方注释说，这是 LongAdder（分散累加器） 的一种特化实现[5]。

调用 size（数量方法） 时，把 baseCount 和所有格子加起来（sumCount）[6]。加的过程中，其他线程还在增删记录，所以并发时得到的是一个 估计值 。官方推荐用 mappingCount（映射数量方法） 代替 size（数量方法）：它返回 long，记录数超过 int 范围时也不会被截断。它同样是估计值[6]。

七、检验：先关掉上面，凭记忆做

5 道题：先回答，再展开核对

1. counts 里 dept-A 的值是 3。两个线程同时各执行一次 counts.merge("dept-A", 1, Integer::sum)。结果是？

• A. 一定是五
• B. 可能是四
• C. 可能是三

2. JDK 8 以后，往一个空桶放入第一个节点时，用的是什么方式？

• A. 锁住整张表放入
• B. 比较并交换放入
• C. 锁所在分段放入

3. 某个桶的链表长度达到 8，但数组长度只有 16。接下来会怎样？

• A. 转成红黑树
• B. 直接抛异常
• C. 先扩容数组

4. 在 ConcurrentHashMap（并发哈希映射） 上调用 get(k) 返回了 null（空值），说明什么？

• A. 没有这个键
• B. 值存的是空
• C. 两种都可能

5. 其他线程正在并发插入时，调用 size() 得到的是？

• A. 一定精确的
• B. 可能不精确
• C. 总是偏小的

代码改错：找出所有并发问题

下面的方法登记部门的待办审批，同时统计总待办数，多个线程会同时调用它。写出 ①②③ 各自会丢掉什么，再写出修改后的方法。

ConcurrentHashMap<String, List<String>> todo = new ConcurrentHashMap<>();
ConcurrentHashMap<String, Integer> total = new ConcurrentHashMap<>();

void addTodo(String dept, String approvalId) {
    if (!todo.containsKey(dept)) {          // ①
        todo.put(dept, new ArrayList<>());
    }
    todo.get(dept).add(approvalId);          // ②
    Integer n = total.get("all");            // ③
    total.put("all", n == null ? 1 : n + 1);
}

验证：这是待改的错误代码，不要直接使用。参考答案在 JDK 17 和 21 上用 8 个线程登记 20 万条，总数与列表条数都正确（2026-10-03 运行）。

void addTodo(String dept, String approvalId) {
    todo.computeIfAbsent(dept, d -> Collections.synchronizedList(new ArrayList<>()))
        .add(approvalId);
    total.merge("all", 1, Integer::sum);
}

八、用完整回答检验理解

连续回答下面四问，可以写下来，也可以先口述再整理成文字。写完再对照各节的参考回答。

1. ConcurrentHashMap（并发哈希映射） 怎么保证线程安全？JDK 7 和 8 有什么不同？
2. 说一下 put（写入方法） 的流程。
3. 它是线程安全的，为什么你的统计代码还会算错？怎么改？
4. 说一个适合用它的场景，说明为什么，以及要注意哪些限制。

练习：请在自己的笔记中写出答案，再展开参考内容核对。

九、常见追问

每问先自己答，再展开核对。答案都在前面各节里。

关于线程安全边界（第一、三节）

关于原子方法（第二节）

关于内部实现（第四、五节）

应用场景：可能用在哪里（候选）

十、隔日复测：明天换条件再答（约 5 分钟）

主来源与引用

1. [1] 读取、遍历、可见性、空值： 官方类说明，原文存于本机官方摘录开头。

2. [2] 四个原子方法： 同一文档中 putIfAbsent（不存在才放入的方法）、computeIfAbsent（缺失时计算的方法）、compute（原子重算方法）、merge（原子合并方法） 的说明，包括“short and simple”和不得修改本表的要求。摘录在同一文件中部。

3. [3] ArrayList（可变数组列表） 并发修改： 官方说明要求外部同步，或用 Collections.synchronizedList 包装。摘录在同一文件末尾。

4. [4] HashMap（普通哈希映射） 与 Collections.synchronizedMap（同步映射包装方法）： 同一摘录中的对应章节。

5. [5] 内部实现： Java 21 源码里的 Implementation overview（实现注释），包括空桶 CAS（比较并交换）、桶头加锁、转发节点、协助扩容、计数方式、Segment（分段锁） 仅用于兼容。摘录在同一文件中部。

6. [6] put（写入方法） 流程与计数源码： 本机 Temurin 21.0.10 的 putVal、treeifyBin、addCount、sumCount、mappingCount（映射数量方法） 原文。摘录在同一文件末尾（2026-10-03 补录）。

7. [JG] JavaGuide： 集合面试题（下），用于选题参考、JDK 7 分段锁结构（本机没有 JDK 7 源码可对照）、Hashtable（旧式同步哈希表） 对比，以及 Doug Lea 关于 null（空值） 的原话转引。

本课速查表 · 完整术语表 · 第5课 · 第4课 · 第3课

学完后，记下判断理由和仍不确定的地方。隔日回看时先尝试回答，再核对课程里的解释。