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 不存在时会被调用，但该函数**可能被执行多次**，即使最终只插入一个结果。
立即学习“Java免费学习笔记（深入）”；
原因在于：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)再遍历——但注意内存和性能开销
get 再 put）都得靠 compute 系列方法或外部同步，这点常被忽略。 
