登录
首页 >  文章 >  java教程

ConcurrentHashMap原理与并发机制详解

时间:2026-02-21 15:45:45 304浏览 收藏

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)来实现更细粒度控制。

这意味着:多个线程往不同桶里写,完全不互斥;只有哈希冲突撞到同一个桶,才可能触发同步块。实际压测中,并发写入吞吐量通常比 Hashtablesynchronized(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,会主动加入迁移队列,而不是等待

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

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

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>