ConcurrentHashMap线程安全原理详解

来到golang学习网的大家，相信都是编程学习爱好者，希望在这里学习文章相关编程知识。下面本篇文章就来带大家聊聊《ConcurrentHashMap如何保证线程安全？》，介绍一下，希望对大家的知识积累有所帮助，助力实战开发！

ConcurrentHashMap线程安全靠分段锁（JDK7）或桶级synchronized+CAS（JDK8+），get无锁、put只锁对应桶；size()/isEmpty()非强一致，推荐mappingCount()；computeIfAbsent中mappingFunction可能多次执行，需幂等；迭代器弱一致性，不抛ConcurrentModificationException。

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

它不锁整个 Map，而是把数据分段（JDK 7）或按 Node 桶（JDK 8+）细粒度加锁。关键在于：put、get、computeIfAbsent 这些操作在多数场景下无需阻塞其他线程读写——get 完全无锁，put 只锁对应 Node 所在的桶（即 table[i]），不是整个 table。

常见误解是“它内部用了 ReentrantLock”，其实 JDK 8 起已改用 Unsafe.compareAndSet + synchronized 锁单个桶头节点，更轻量；JDK 7 确实用了 Segment 数组 + 每段一把 ReentrantLock，但 Segment 数量固定（默认 16），锁粒度仍远小于 Hashtable 的全局 synchronized。

为什么 size() 和 isEmpty() 不是强一致的

这两个方法返回的是近似值，不保证实时准确。因为 ConcurrentHashMap 不会在调用时加全局锁去遍历所有桶统计——那样会严重拖慢高并发读场景。

• size() 在 JDK 8 中返回的是一个通过 CAS 累加的 baseCount 加上各桶中 CounterCell 的和，但中间可能有未 flush 的计数更新
• isEmpty() 只检查 baseCount == 0 且所有桶头为 null，但某个桶刚插入元素、计数还没同步到 baseCount 时，就可能误判为空
• 如果业务需要精确大小（比如限流、校验），应改用 mappingCount()——它返回 long 类型，语义更明确，但仍非强一致（只是比 size() 更可靠一点）

computeIfAbsent 为什么可能被多次执行

这是最容易踩坑的一点：传入的 mappingFunction 在 key 不存在时会被调用，但该函数**可能被执行多次**，即使最终只插入一个结果。

原因在于：ConcurrentHashMap 不会在调用前加锁判断 key 是否存在，而是先尝试 CAS 插入一个占位 Node（ForkJoinPool.commonPool() 中的异步计算也可能触发重试），再调用函数。若多个线程同时发现 key 缺失，都进入计算流程，就会导致函数重复执行。

示例：

map.computeIfAbsent("key", k -> {
    System.out.println("I'm called!"); // 可能打印多次
    return expensiveInit();
});

解决办法只有两种：

• 确保 mappingFunction 是幂等的（比如查缓存、构造不可变对象）
• 改用 compute 或手动加锁（如 synchronized(map)）控制初始化逻辑，但会损失并发性

迭代器弱一致性，不抛 ConcurrentModificationException

keySet().iterator()、entrySet().iterator() 返回的迭代器是“弱一致性”（weakly consistent）：不会抛 ConcurrentModificationException，也不保证反映某一时刻的快照。它可能跳过刚插入的元素，也可能重复返回已被删除的元素（取决于遍历进度与结构变更时机）。

这意味着：

• 不能依赖迭代器做“全量校验”或“原子性遍历处理”
• 不要在遍历时调用 remove()（虽然支持，但行为难预测）；如需边遍历边删，请用 forEach + computeIfPresent 等原子方法
• 若必须强一致性遍历，得自己加锁或转成 new HashMap(map) 再遍历——但注意内存和性能开销

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