登录
首页 >  文章 >  java教程

ConcurrentHashMap安全原理详解

时间:2026-01-20 13:12:40 213浏览 收藏

golang学习网今天将给大家带来《Java并发映射机制解析:ConcurrentHashMap安全原理》,感兴趣的朋友请继续看下去吧!以下内容将会涉及到等等知识点,如果你是正在学习文章或者已经是大佬级别了,都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家!

ConcurrentHashMap线程安全靠分段锁(JDK7)或CAS+synchronized单节点锁(JDK8+),get()无锁,put()仅锁桶头,size()非O(1)且有误差,迭代器弱一致性,forEach()不支持遍历时修改,computeIfAbsent()可能重复初始化,扩容时get()可能读到旧值。

在Java中ConcurrentHashMap如何保证安全_Java并发映射机制解析

ConcurrentHashMap 的线程安全不是靠 synchronized 全局锁

它用的是分段锁(JDK 7)或 CAS + synchronized 锁单个 Node(JDK 8+),只锁哈希桶链表/红黑树的头节点,而不是整个 Map。这意味着多个线程可以同时读写不同桶的数据,吞吐量远高于 HashtableCollections.synchronizedMap()

常见误解是“它内部全加了锁”,实际在 JDK 8 中:get() 完全无锁(依赖 volatile 语义),put() 只在必要时对桶首节点加 synchronized,且锁粒度极小。

  • size() 不是 O(1),而是遍历所有 CounterCell 累加,可能有短暂误差(最终一致)
  • containsKey()get() 行为一致,都无锁、不阻塞
  • 迭代器弱一致性:不抛 ConcurrentModificationException,但可能漏掉或重复看到刚插入/删除的元素

为什么不能用 forEach() 替代 for-loop 遍历 ConcurrentHashMap

forEach()ConcurrentHashMap 自带的并行遍历方法,底层调用 Traverser 分段扫描,但它的行为和传统 for-each 循环(即 entrySet().iterator())有本质区别:

  • entrySet().iterator() 返回的是弱一致性迭代器,遍历时允许并发修改,但不保证看到最新状态
  • forEach(BiConsumer) 在遍历中若其他线程修改了正在访问的桶,该次遍历仍会继续,但不会反映那些修改;它不阻塞也不重试
  • 更关键的是:forEach() 无法在遍历中安全地执行 remove()computeIfAbsent() —— 这些操作会引发 IllegalStateException 或不可预期结果

真正需要边遍历边更新时,应改用 replaceAll()computeIfPresent() 等原子方法,或先收集 key 再批量处理。

computeIfAbsent() 在高并发下可能重复初始化

computeIfAbsent() 声称“只计算一次”,但前提是传入的 mappingFunction 是幂等的。它底层逻辑是:先 get(),没命中再加锁、再次检查、再调用函数。两次检查之间存在窗口,若 mappingFunction 创建对象开销大或有副作用,就可能被多个线程同时触发。

典型错误场景:

map.computeIfAbsent(key, k -> new ExpensiveObject(k)); // 可能创建多个实例

解决方式:

  • 确保 mappingFunction 本身轻量且无副作用
  • 若必须延迟初始化重型资源,改用双重检查 + putIfAbsent() 组合
  • JDK 9+ 提供了 computeIfAbsent(key, mappingFunction) 的替代思路:用 ConcurrentHashMap 配合 FutureTask 缓存初始化任务

扩容时 get() 为什么不会阻塞,但可能看到旧值

ConcurrentHashMap 扩容是渐进式迁移(JDK 8 中通过 transfer() 方法),由首个触发扩容的线程启动,后续 put/get 线程协助迁移。关键点在于:get() 遇到正在迁移的桶(即 ForwardingNode),会直接跳转到新表查询。

但这个过程不是原子切换:

  • 旧表中部分桶已迁走,部分还没动
  • 如果一个 key 在旧表中尚未迁移,get() 会从旧表读到旧值;若此时新表已写入新值,旧值就是“过期”的
  • 这种不一致仅存在于迁移窗口期(通常很短),属于最终一致性范畴,不是 bug

所以不要依赖 get() 立即看到 put() 后的最新值——这和 volatile 字段类似,只能保证可见性,不保证实时性。

今天关于《ConcurrentHashMap安全原理详解》的内容介绍就到此结束,如果有什么疑问或者建议,可以在golang学习网公众号下多多回复交流;文中若有不正之处,也希望回复留言以告知!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>