ConcurrentHashMap 通过分段锁（JDK7）或CAS+volatile+synchronized单桶锁（JDK8）避免全局锁；get()无锁但依赖volatile可见性；computeIfAbsent可能重复计算；扩容采用分批迁移与协助机制保障读写不阻塞。
ConcurrentHashMap 是怎么避免全局锁的
它不靠 synchronized 锁整个 Map，而是把数据分段——早期 JDK 7 用 Segment 数组，每段独立加锁；JDK 8 彻底改用 Node 数组 + 链表/红黑树，配合 volatile + CAS + synchronized 锁单个桶（bin）来实现更细粒度控制。
这意味着：多个线程往不同桶里写，完全不互斥；只有哈希冲突撞到同一个桶，才可能触发同步块。实际压测中，并发写入吞吐量通常比 Hashtable 或 synchronized(new HashMap()) 高数倍。
注意点：
- JDK 8 中
synchronized锁的是Node首节点，不是整个链表或树，所以扩容时也能并发读写其他桶 -
size()不再是 O(1)，而是遍历所有 bin 的baseCount和每个CounterCell求和，可能有短暂延迟 - 不要误以为“无锁”——它只是锁粒度小，
put()、remove()等关键操作仍有同步逻辑
为什么 computeIfAbsent 有时会重复计算
这是最常被踩的坑：computeIfAbsent 在 key 不存在时，会先调用你传入的 mappingFunction，再用 CAS 尝试插入结果；但如果多个线程同时发现 key 缺失，它们各自都会执行一遍函数，最后只有一条结果成功落库，其余计算白费，还可能引发副作用（比如重复发请求、创建对象）。
立即学习“Java免费学习笔记（深入）”；
典型场景：
- 缓存穿透防护中用
computeIfAbsent("user:123", id -> loadFromDB(id))，并发请求下loadFromDB可能被调用多次 - 函数里有 IO 或耗时操作，性能直线下滑
解决办法不是不用它，而是加一层双重检查或用 Future 包装：
