java 8 中 concurrenthashmap 不再用分段锁，因其固定段数、扩容难、内存开销大且空闲段仍占锁资源；改用 node 数组 + cas + synchronized 锁单个桶头或红黑树根节点，大幅降低锁粒度。
ConcurrentHashMap 在 Java 8 中为什么不再用分段锁
因为分段锁（Segment）在高并发写场景下成了瓶颈：段数固定、扩容困难、内存开销大，且多数段长期空闲却仍占锁资源。Java 8 彻底移除了 Segment，改用更轻量的 Node 数组 + CAS + 细粒度 synchronized 锁单个桶（bin），把锁范围从“一段数组”缩小到“一个链表头节点”甚至“一个红黑树根节点”。
常见错误现象：ConcurrentHashMap 在 Java 7 中大量 put 时出现 IllegalStateException: Recursive update 或吞吐量远低于预期——大概率是误用了旧版分段机制，或没意识到段竞争已成瓶颈。
- Java 7 的
ConcurrentHashMap默认 16 段，即使只写一个 key，也要竞争其中一段的锁；Java 8 下，只要不哈希冲突到同一桶，完全无锁 - 扩容时 Java 7 是整段复制，Java 8 改为多线程协作迁移，每个线程负责一部分
Node，且迁移中仍可读写 - 注意兼容性：Java 8+ 的
size()不再是 O(1)，而是遍历所有桶计数（可能有误差），如需精确值应改用mappingCount()
什么时候会触发 synchronized 锁住整个链表头
不是每个 put 都上锁，只有当目标桶（tab[i]）非空且需要修改其结构时，才对该桶的首节点加 synchronized。比如插入新节点、链表转红黑树、或扩容时迁移该桶。
使用场景举例：多个线程同时向同一个哈希桶写入不同 key（哈希碰撞），此时它们会竞争同一把锁——这是 Java 8 唯一的“写热点”，但比 Java 7 的段锁粒度细得多。
立即学习“Java免费学习笔记（深入）”；
- 锁对象是
tab[i]对应的首个Node（即桶头），不是ConcurrentHashMap实例本身 - 如果桶是红黑树结构，锁的是树的根节点（
TreeBin的lock字段），不是整个树 - 读操作（
get）全程无锁，靠 volatile 语义和数组引用的不可变性保证可见性
CAS 在 ConcurrentHashMap 初始化和扩容中的关键作用
CAS 主要用于无锁地更新数组引用和控制变量，比如初始化时用 U.compareAndSetObject(this, SIZECTL, sc, -1) 竞争初始化权，扩容时用 transferIndex 协调多线程分片迁移。
容易踩的坑：sizeCtl 这个字段含义复杂——负数表示正在扩容（-1 表示初始化中，-N 表示有 N-1 个线程在帮忙扩容），正数则可能是初始容量或下次扩容阈值。直接读写它极易出错。
- 初始化失败不会抛异常，而是让后续线程重试；若反复失败，说明存在严重竞争或 JVM 内存问题
- 扩容期间，新老数组并存，
get会先查新数组，查不到再查旧数组，确保不丢数据 -
helpTransfer()被调用时，当前线程会主动参与迁移，但前提是nextTable != null且自己能抢到一个迁移区间
链表转红黑树的阈值和实际触发条件
不只是看链表长度 ≥ 8，还必须满足数组长度 ≥ 64，否则优先选择扩容而非树化。这是为了防止在小数组中过早树化，带来不必要的结构开销。
真实触发点在 treeifyBin() 方法里：先检查 tab.length （即 64），不满足就只扩容；满足才把链表转为 <code>TreeBin。
- 红黑树节点类型是
TreeNode，但它被包在TreeBin里，后者才是桶数组里的实际元素，负责管理锁和读写协调 - 树退化回链表发生在删除后节点 ≤ 6，且退化操作也是在
untreeify()中完成，不是实时的 - 注意：哈希值相同且
equals返回 true 的 key 会被视为重复，不会形成链表/树节点，而是覆盖 value
最常被忽略的一点：Java 8 的 ConcurrentHashMap 并不保证迭代器的强一致性，keySet().iterator() 可能漏掉扩容中新插入的元素，也可能重复看到某个元素。如果业务依赖“遍历时看到全部当前数据”，就得自己加同步或换用其他结构。
