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免费学习笔记（深入）”；
典型场景：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 缓存穿透防护中用
computeIfAbsent("user:123", id -> loadFromDB(id))，并发请求下loadFromDB可能被调用多次 - 函数里有 IO 或耗时操作，性能直线下滑
解决办法不是不用它，而是加一层双重检查或用 Future 包装：
ConcurrentHashMap<String, CompletableFuture<User>> cache = new ConcurrentHashMap<>();
cache.computeIfAbsent("user:123", k -> CompletableFuture.supplyAsync(() -> loadFromDB(k)))
.join();
get() 真的完全无锁吗
是的，JDK 8+ 的 get() 方法全程不加锁，靠 volatile 读和数组引用的可见性保证——只要 Node 节点本身字段（如 val）声明为 volatile，且插入时用 UNSAFE.putObjectVolatile 写入，读就能看到最新值。
但要注意边界情况：
- 如果 get 到一个正在扩容的桶，它会去新表查，这个过程仍能保证一致性，但会多一次跳转
- 如果 value 是可变对象（比如
ArrayList），get()返回后你去修改它，不会影响 map 内部，但可能破坏业务逻辑预期 -
get()不保证内存屏障覆盖整个对象图，只保 Node 层级的可见性
扩容时如何做到读写不阻塞
核心是“分批迁移”+“读写协助”：扩容不是一口气搬完，而是每次处理一个 bin；当某个线程发现当前桶已迁移，就顺手帮着搬下一个；而读操作遇到正在迁移的桶，会先查旧表、再查新表，自动兜底。
关键机制：
- 迁移中桶头节点设为
ForkJoinPool.commonPool()不参与，而是用特殊节点ForwardingNode标记“我正搬走”，后续读写都转向新表 -
sizeCtl字段既表示扩容阈值，也作为扩容线程数协调器：负数代表有线程在扩容，绝对值表示待处理的 bin 数量 - 扩容期间
put()如果碰到ForwardingNode，会主动加入迁移队列，而不是等待
真正难的是理解“协助扩容”不是可选优化，而是设计刚需——否则低并发时扩容慢，高并发时又容易卡住部分线程。实际调试时，transferIndex 和 sizeCtl 的变化节奏，往往就是定位扩容瓶颈的第一线索。
