concurrenthashmap 通过“分段锁（jdk 7）→桶级锁+cas（jdk 8）”演进，实现线程安全与高性能统一：用volatile保障读可见、cas处理无竞争写、synchronized仅锁单桶头节点，避免全局锁瓶颈；sizectl状态机协调扩容，forwardingnode保证迁移中读写不中断——本质是“锁得更少、等得更短、错得更少”。
ConcurrentHashMap 的核心面试话术，要围绕“线程安全”“高性能”“演进逻辑”三个关键词展开，不是堆砌术语，而是讲清“为什么这么设计”。底层逻辑不能只背结构，得说透它怎么在不锁全局的前提下，既保证安全又不拖慢读写。
为什么需要 ConcurrentHashMap？
HashMap 非线程安全，多线程 put 可能导致数据丢失、死循环（JDK 1.7 头插法）、或覆盖；Hashtable 和 Collections.synchronizedMap 虽安全，但用的是全局锁，吞吐量低。ConcurrentHashMap 的目标很明确：把“一把大锁”拆成“多个小锁”，让并发写互不干扰，读几乎零成本。
JDK 1.7 到 1.8 的关键演进
这个对比是面试高频点，体现你对技术迭代的理解：
- JDK 1.7：分段锁（Segment）——内部维护一个 Segment 数组（默认 16 个），每个 Segment 是一个加了 ReentrantLock 的小型 HashMap。写操作先定位 Segment，再锁住对应段；读操作靠 volatile 保证可见性，完全无锁。
- JDK 1.8：CAS + 桶级锁——彻底去掉 Segment，回归类似 HashMap 的 Node 数组结构。写操作：空桶用 CAS 插入；非空桶则只锁链表头节点或红黑树根节点；扩容时用 sizeCtl 控制多线程协作，用 ForwardingNode 标记迁移中的桶。
一句话总结演进动因：Segment 固定分段导致并发度僵化、内存开销大；JDK 1.8 用更细粒度的锁 + 无锁路径（CAS），兼顾灵活性与性能。
线程安全到底靠什么？
它不是“完全无锁”，而是“有锁但锁得聪明”：
- volatile 修饰 Node 的 val 和 next 字段，确保读操作看到最新值，无需加锁；
- CAS 用于初始化桶、插入第一个节点等轻量写场景；
- synchronized 只作用于单个桶（链表头或树根），锁范围最小化；
- 扩容过程通过 sizeCtl 状态位协调多线程，避免重复扩容，ForwardingNode 引导访问新数组，保证迁移中仍可读写。
和 HashMap 的本质区别在哪？
别只答“线程安全”，要落到实现差异上：
- 结构上：HashMap 是纯数组+链表+红黑树；ConcurrentHashMap 在此基础上增加了并发控制组件（如 ForwardingNode、CounterCell、sizeCtl）；
- put 流程：HashMap 直接操作，可能出错；ConcurrentHashMap 先尝试 CAS，失败再加锁，还要检查是否正在扩容；
- null 支持：HashMap 允许 key/value 为 null；ConcurrentHashMap 不允许 key 或 value 为 null，避免在并发判断中产生歧义（比如 get 返回 null，无法区分是没找到还是存的就是 null）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
