ConcurrentHashMap在JDK 7中采用Segment分段锁，JDK 8+改用CAS+synchronized单桶锁；前者默认16段，后者锁粒度更细、支持协助扩容，且size()均为近似值。
ConcurrentHashMap 在 Java 中实现分段并发控制的方式，取决于你使用的 JDK 版本：JDK 7 用的是“分段锁（Segment）”，而 JDK 8 及以后彻底改用“CAS + synchronized + 链表/红黑树”方案，不再有传统意义上的“分段”。
JDK 7：基于 Segment 的分段锁机制
在 JDK 7 中，ConcurrentHashMap 内部维护一个 Segment 数组，每个 Segment 本质是一个加了锁的 HashEntry 数组，相当于一个小型的 Hashtable。
- 默认有 16 个 Segment，即最多支持 16 个线程并发写入不同段，互不阻塞
- put 操作时，先根据 key 的 hash 值定位到具体 Segment，再对该 Segment 加锁（可重入锁），其他 Segment 仍可被其他线程操作
- get 不加锁，通过 volatile 修饰的 value 和引用保证可见性
- 扩容是单个 Segment 自行扩容，不影响其他段
JDK 8+：放弃 Segment，转向细粒度锁优化
JDK 8 彻底移除了 Segment，改用更轻量、更灵活的并发策略：
- 底层仍是数组 + 链表/红黑树结构，但锁粒度降到“单个桶（bin）”级别
- put 操作先无锁尝试 CAS 插入；失败后，若该桶头节点已存在，则对头节点 synchronized 加锁（锁对象是链表头或红黑树根）
- 多个线程往不同桶写入完全不冲突；即使哈希冲突，也只锁冲突链/树的头节点，不影响其他桶
- 扩容采用“多线程协助扩容”机制：首次触发扩容的线程初始化新数组，后续 put 发现正在扩容，会主动帮助迁移部分旧桶数据
为什么 JDK 8 要去掉 Segment？
Segment 虽然比 Hashtable 更高效，但仍存在一些局限：
立即学习“Java免费学习笔记（深入）”；
- Segment 是可重入锁，本身有较大内存和调度开销
- 固定段数（默认 16）无法动态适配 CPU 核心数或实际并发压力
- 跨段操作（如 size()、containsValue()）需遍历所有 Segment 并加锁，性能差且结果可能不精确
- CAS 和 synchronized 在现代 JVM 中优化得更好，单桶锁的实际竞争概率更低
使用建议与注意事项
无论哪个版本，ConcurrentHashMap 都不是“绝对线程安全”的万能替代品：
- 复合操作（如“检查再插入”）仍需手动同步，推荐用 computeIfAbsent / merge 等原子方法
- 迭代器弱一致性：遍历时允许其他线程修改，不会抛 ConcurrentModificationException，但可能看不到最新更新
- size() 返回的是近似值（JDK 8 中通过 baseCount + CounterCell 数组估算），如需精确计数，应考虑 LongAdder 或额外同步
- 不要把它当“线程安全的 HashMap”盲目替换 —— 如果场景是读多写少且无强一致性要求，它很合适；但涉及复杂逻辑时，仍要审视是否真需要它的并发能力
基本上就这些。理解它“怎么锁”比死记 API 更重要 —— 锁在哪、锁多久、谁在等，直接决定你的并发性能和正确性。
