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 对象内部状态。例如:
立即学习“Java免费学习笔记(深入)”;
ConcurrentHashMapmap = 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(),且二者逻辑不能依赖可变字段










