ConcurrentHashMap通过CAS、synchronized细粒度锁和volatile机制实现线程安全，JDK 8后摒弃Segment改用数组+链表/红黑树结构，仅对单个桶加锁并结合volatile保证可见性，读操作无锁因value和next为volatile且结构修改受锁保护，相比Hashtable全局锁大幅减少竞争，提升并发性能，同时迭代器提供弱一致性，不抛ConcurrentModificationException但可能读到中间状态。
ConcurrentHashMap 在 Java 中通过多种机制实现线程安全，同时兼顾性能，避免了像 Hashtable 那样使用全局锁带来的并发瓶颈。其核心设计在不同 JDK 版本中有所变化，主要以 JDK 8 为分界点。
JDK 8 及以后：CAS + synchronized + volatile
从 JDK 8 开始，ConcurrentHashMap 不再使用 Segment 分段锁，而是采用更细粒度的同步策略：
- 数组 + 链表/红黑树结构：底层数据结构与 HashMap 类似，使用 Node 数组存储数据，冲突时转为链表或红黑树。
- synchronized 锁单个桶（bin）：当多个线程写入同一个哈希桶时，仅对该桶的第一个节点加 synchronized 锁，保证同一时间只有一个线程能修改该桶，其他桶仍可并发访问。
- CAS 操作保证原子性：在插入第一个节点、扩容标记等关键操作中，使用 CAS（Compare and Swap）来确保多线程环境下的无锁更新，例如通过 Unsafe 类操作 volatile 变量。
- volatile 关键字保障可见性：Node 节点中的 value 和 next 指针被声明为 volatile，确保一个线程的修改对其他线程立即可见。
- 扩容时并发协助：当某个线程发现需要扩容时，会触发 transfer 操作，其他线程在插入或查询时也可能协助一起扩容，提升效率。
读操作为何不需要加锁？
ConcurrentHashMap 的读操作（如 get）完全无锁，这得益于以下设计：
- Node 的 value 和 next 使用 volatile 修饰，保证读取时能看到最新的写入结果。
- 链表和红黑树的结构修改在加锁保护下进行，但遍历过程中即使结构变化，也能保证不会出现结构性破坏（如循环引用），从而允许无锁读取。
为什么比 Hashtable 更高效？
Hashtable 使用 synchronized 修饰整个方法，导致所有操作争用同一把锁，串行化严重。而 ConcurrentHashMap 将锁细化到桶级别，大大减少了锁竞争，提升了并发吞吐量。
立即学习“Java免费学习笔记（深入）”；
基本上就这些，它通过结合 CAS、synchronized 细粒度锁和 volatile 可见性机制，在保证线程安全的同时，实现了高并发性能。不复杂但容易忽略的是，它的“弱一致性”读——迭代器不抛出 ConcurrentModificationException，但可能反映某一时刻的混合状态。
