ConcurrentHashMap并发安全详解

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《Java并发安全：ConcurrentHashMap使用详解》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

ConcurrentHashMap线程安全但非万能：JDK8+用CAS+synchronized实现分段锁，get无锁、put仅锁bin头节点；复合操作须用computeIfAbsent等原子方法；size()和isEmpty()返回近似值；key/value需自身线程安全且key应不可变。

ConcurrentHashMap 是线程安全的，但不是万能锁

它通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）实现高并发读写，**不阻塞全部操作**。这意味着 get() 几乎无锁，而 put() 只锁定对应 bin 的头节点——但如果你手动用 synchronized 包裹整个 map 操作，反而会抵消它的并发优势。

别在循环里直接调用 remove() 或 computeIfAbsent() 做复合逻辑

像“检查是否存在 → 不存在则创建”这种逻辑，看似简单，但分开写 containsKey() + putIfAbsent() 仍可能引发竞态：两次调用之间其他线程已插入。正确做法是用原子方法：

map.computeIfAbsent(key, k -> {
    // 这里创建新对象的逻辑只会在 key 确实不存在时执行一次
    return new ExpensiveObject(k);
});

• computeIfAbsent() 和 merge() 是原子的，适合构建缓存场景
• 避免在 lambda 中抛出受检异常（需包装为 RuntimeException）
• 如果初始化逻辑可能失败且需重试，不要依赖 computeIfAbsent 自动重入——它不保证重试，失败即返回 null 或抛异常

size() 和 isEmpty() 不是强一致性快照

这两个方法返回的是近似值。JDK 8+ 中 size() 实际调用 sumCount()，遍历每个 segment 的 baseCount 和 counterCells 数组，但过程中其他线程仍在修改，结果可能滞后一个更新周期。实际业务中：

• 不要用 size() == 0 判断是否可安全关闭资源——改用 map.isEmpty() 虽也不绝对可靠，但语义更清晰
• 需要精确计数？改用 LongAdder 单独维护计数器，或用 mappingCount()（返回 long，比 size() 更准确，但仍非严格实时）
• 遍历时别依赖 size() 控制 for 循环次数，改用 entrySet().iterator() 或增强 for

key 和 value 仍需保证自身线程安全

ConcurrentHashMap 只保证 map 结构操作的线程安全，不约束 key/value 对象内部状态。例如：

ConcurrentHashMap map = new ConcurrentHashMap();
map.computeIfAbsent("log", k -> new StringBuilder()).append("msg"); // ❌ 危险！StringBuilder 非线程安全

• value 是可变对象（如 ArrayList、SimpleDateFormat）时，外部仍需同步或改用不可变/线程安全替代品（如 CopyOnWriteArrayList、DateTimeFormatter）
• key 最好是不可变类（如 String、Integer），否则若 key 在插入后被修改导致 hashCode() 变化，后续 get() 将找不到该 entry
• 自定义 key 类必须正确重写 hashCode() 和 equals()，且二者逻辑不能依赖可变字段

真正容易被忽略的是：ConcurrentHashMap 的“安全”仅限于它自己暴露的 API 行为边界。一旦你把它当普通容器去塞可变对象、在外层加锁、或依赖非原子组合操作，线程安全就立刻瓦解。

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