jdk 1.8 中 concurrenthashmap 彻底移除了 segment 和分段锁，改用 cas + 单桶（table[i]）级 synchronized 实现更细粒度并发控制；size()、扩容等均基于 table 数组与 countercell 协作完成，无任何“段”概念。
ConcurrentHashMap 在 JDK 1.8 中根本没有分段锁 —— 它彻底移除了 Segment，所谓“分段锁优化”是误传或混淆了 JDK 1.7 的设计。真正起作用的是 CAS + 单桶（table[i]）级 synchronized，粒度比 Segment 更细，也更轻量。
为什么说“分段锁优化”这个说法本身就不成立
JDK 1.7 确实用 Segment 数组实现分段锁，每个 Segment 是一个独立的 ReentrantLock，并发度默认为 16；但 JDK 1.8 的源码里已完全删掉 Segment 类，ConcurrentHashMap 的核心字段只剩 table、nextTable、sizeCtl 和 baseCount。所有“分段”“段锁”“并发度设置”等概念在 1.8 中既无对应类，也无对应逻辑。
- 调用
new ConcurrentHashMap(16, 0.75f, 32)时，第三个参数（原 JDK 1.7 的 concurrencyLevel）会被忽略，仅用于计算初始容量 -
size()不再遍历多个 Segment 求和，而是依赖baseCount+CounterCell数组的 CAS 累加 - 扩容不再按 Segment 分批进行，而是由多个线程协作迁移
table中的桶（transfer方法）
tabAt 和 casTabAt 是 CAS 操作的实际入口
所有无锁写入都围绕这两个 Unsafe 辅助方法展开，它们直接操作 table 数组的指定下标，不依赖锁：
-
tabAt(table, i)：volatile 读取table[i]，保证看到其他线程写入的最新节点 -
casTabAt(table, i, c, v)：比较并交换table[i]，仅当当前值等于c时才设为v；失败则重试（如putVal中的 for 自旋） - 初始化
table、插入首个节点、协助扩容标记位（MOVED）、更新计数器等关键路径都优先走 CAS
注意：casTabAt 失败不等于操作失败，而是进入下一步：检查是否需要加锁（比如该桶已有节点，需 synchronized 链表头节点）。
什么时候会触发 synchronized？只锁链表/红黑树的首节点
不是锁整个数组，也不是锁某个逻辑“段”，而是当 CAS 插入失败且桶非空时，对 table[i] 当前引用的首节点加锁：
- 锁对象是
f（即tabAt(table, i)返回的 Node），不是this，也不是全局锁 - 加锁后检查该桶是否已被其他线程改为红黑树（
fh ），若是则走树的插入逻辑；否则遍历链表或插入尾部 - 红黑树的读写操作（
putTreeVal、find）内部也只对树根节点加锁，不影响其他桶 - 这意味着：两个线程往不同桶（
i != j）写，完全无竞争；往同一桶写，才可能因锁首节点而短暂阻塞
容易被忽略的细节：volatile 的边界与 sizeCtl 的多重语义
volatile 修饰的字段不是万能的，它只保证单变量的可见性，不保证复合操作原子性。例如：
-
table是 volatile，但table[i] = new Node(...)这一赋值本身是原子的；而table[i].val = value依赖节点内val字段也是 volatile 才可见 -
sizeCtl是个“多面手”：初始化时为 -1，扩容中为 -(1 + 参与扩容线程数)，扩容结束前为新容量阈值，正常运行时为下次扩容阈值；读写它必须配合 CAS，不能直接赋值 - 链表转红黑树的条件有两个缺一不可：
binCount >= TREEIFY_THRESHOLD (8)且tab.length >= MIN_TREEIFY_CAPACITY (64)；少一个都不会触发树化，这点常被调试时忽略
真正难啃的部分不在“怎么加锁”，而在理解 sizeCtl 状态机、transfer 协作迁移协议、以及 CounterCell 如何避免计数热点 —— 这些才是 JDK 1.8 并发设计的实质复杂点。
