在Java里ConcurrentHashMap的核心原理_Java并发Map解析

ConcurrentHashMap 通过分段锁（JDK7）或CAS+volatile+synchronized单桶锁（JDK8）避免全局锁；get()无锁但依赖volatile可见性；computeIfAbsent可能重复计算；扩容采用分批迁移与协助机制保障读写不阻塞。

ConcurrentHashMap 是怎么避免全局锁的

它不靠 synchronized 锁整个 Map，而是把数据分段——早期 JDK 7 用 Segment 数组，每段独立加锁；JDK 8 彻底改用 Node 数组 + 链表/红黑树，配合 volatile + CAS + synchronized 锁单个桶（bin）来实现更细粒度控制。

这意味着：多个线程往不同桶里写，完全不互斥；只有哈希冲突撞到同一个桶，才可能触发同步块。实际压测中，并发写入吞吐量通常比 Hashtable 或 synchronized(new HashMap()) 高数倍。

注意点：

• JDK 8 中 synchronized 锁的是 Node 首节点，不是整个链表或树，所以扩容时也能并发读写其他桶
• size() 不再是 O(1)，而是遍历所有 bin 的 baseCount 和每个 CounterCell 求和，可能有短暂延迟
• 不要误以为“无锁”——它只是锁粒度小，put()、remove() 等关键操作仍有同步逻辑

为什么 computeIfAbsent 有时会重复计算

这是最常被踩的坑：computeIfAbsent 在 key 不存在时，会先调用你传入的 mappingFunction，再用 CAS 尝试插入结果；但如果多个线程同时发现 key 缺失，它们各自都会执行一遍函数，最后只有一条结果成功落库，其余计算白费，还可能引发副作用（比如重复发请求、创建对象）。

立即学习“Java免费学习笔记（深入）”；

典型场景：

• 缓存穿透防护中用 computeIfAbsent("user:123", id -> loadFromDB(id))，并发请求下 loadFromDB 可能被调用多次
• 函数里有 IO 或耗时操作，性能直线下滑

解决办法不是不用它，而是加一层双重检查或用 Future 包装：

Face++旷视

Face⁺⁺ AI开放平台

下载

ConcurrentHashMap> cache = new ConcurrentHashMap<>();
cache.computeIfAbsent("user:123", k -> CompletableFuture.supplyAsync(() -> loadFromDB(k)))
      .join();

get() 真的完全无锁吗

是的，JDK 8+ 的 get() 方法全程不加锁，靠 volatile 读和数组引用的可见性保证——只要 Node 节点本身字段（如 val）声明为 volatile，且插入时用 UNSAFE.putObjectVolatile 写入，读就能看到最新值。

但要注意边界情况：

• 如果 get 到一个正在扩容的桶，它会去新表查，这个过程仍能保证一致性，但会多一次跳转
• 如果 value 是可变对象（比如 ArrayList），get() 返回后你去修改它，不会影响 map 内部，但可能破坏业务逻辑预期
• get() 不保证内存屏障覆盖整个对象图，只保 Node 层级的可见性

扩容时如何做到读写不阻塞

核心是“分批迁移”+“读写协助”：扩容不是一口气搬完，而是每次处理一个 bin；当某个线程发现当前桶已迁移，就顺手帮着搬下一个；而读操作遇到正在迁移的桶，会先查旧表、再查新表，自动兜底。

关键机制：

• 迁移中桶头节点设为 ForkJoinPool.commonPool() 不参与，而是用特殊节点 ForwardingNode 标记“我正搬走”，后续读写都转向新表
• sizeCtl 字段既表示扩容阈值，也作为扩容线程数协调器：负数代表有线程在扩容，绝对值表示待处理的 bin 数量
• 扩容期间 put() 如果碰到 ForwardingNode，会主动加入迁移队列，而不是等待

真正难的是理解“协助扩容”不是可选优化，而是设计刚需——否则低并发时扩容慢，高并发时又容易卡住部分线程。实际调试时，transferIndex 和 sizeCtl 的变化节奏，往往就是定位扩容瓶颈的第一线索。