当前位置：首页 > 文章列表 > 文章 > java教程 > ConcurrentHashMap原理与并发机制详解

ConcurrentHashMap原理与并发机制详解

2026-02-21 15:45:45 0浏览收藏

ConcurrentHashMap 的核心魅力在于它通过精妙的并发设计——从 JDK7 的分段锁到 JDK8 的 CAS+volatile+单桶 synchronized 锁——彻底摆脱了全局锁桎梏，在保障线程安全的同时实现极高吞吐量；它让 get() 真正无锁却依赖 volatile 可见性、使 computeIfAbsent 虽便利却暗藏重复计算陷阱、以分批迁移与读写协助机制让扩容成为“隐形”操作，全程不阻塞读写；理解这些机制，不仅是掌握一个集合类，更是深入 Java 并发编程底层逻辑的关键入口。

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

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 缺失，它们各自都会执行一遍函数，最后只有一条结果成功落库，其余计算白费，还可能引发副作用（比如重复发请求、创建对象）。

典型场景：

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

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

ConcurrentHashMap<String, CompletableFuture<User>> 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 的变化节奏，往往就是定位扩容瓶颈的第一线索。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。