彻底讲透 JDK1.8 ConcurrentHashMap 线程安全原理全网最通俗图文完整版前言HashMap 线程不安全多线程并发 put 会出现数据覆盖、数据丢失JDK1.7 还会出现扩容死循环。为了解决并发安全问题JDK1.8 的 ConcurrentHashMap 抛弃了 JDK1.7 的 Segment 分段锁采用volatile CAS synchronized 并发扩容四大机制实现高性能线程安全。本文从零梳理底层结构、每一个机制的作用位置、适用场景、图文对照彻底搞懂 CHM 如何保证并发安全。一、底层数据结构总览图文JDK1.8 ConcurrentHashMap 底层结构数组 链表 红黑树1.1 普通链表桶结构无树化【volatile 数组引用】 transient volatile NodeK,V[] table 数组堆内存结构 table[0] → null table[1] → Node1桶头节点 / synchronized 锁对象 ↓ next(volatile) Node2 ↓ next(volatile) Node3 核心规则数组中只有桶头 Node的引用存在 table 数组格子中链表后续 Node2、Node3不在数组中仅靠 Node.next 指针串联所有 Node 对象全部创建在堆内存1.2 红黑树桶结构树化后table[2] → TreeBin桶头、synchronized 锁对象继承 Node ├─ root → TreeNode红黑树根节点❗不是桶头 ├─ 挂载大量 TreeNode 左右子节点 └─ 内置读写锁提升并发读性能 重中之重90%人混淆树化后数组桶头不是 TreeNode而是TreeBinTreeNode 只是内部数据节点永远不会被锁synchronized 锁的是桶头 TreeBin 对象二、volatile 两层作用核心难点彻底拆解ConcurrentHashMap 有两套独立的 volatile 机制互不干扰这是最容易混淆的知识点。2.1 第一层volatile 修饰 table 数组引用transient volatile NodeK,V[] table;作用保证「数组引用切换」的可见性关键点纠正volatile不修饰数组内容、不修饰数组元素仅修饰table 这个变量保存数组堆地址数组一旦 new 出来自身堆地址永远不变volatile 只负责扩容/初始化时 table 新数组地址全局可见场景首次 put 初始化数组扩容结束切换新数组table nextTable保证所有线程立刻识别新数组不会继续读写旧数组避免数据错乱。2.2 第二层volatile 修饰 Node 内部字段static class NodeK,V { final int hash; final K key; volatile V val; // 值可见性 volatile NodeK,V next; // 指针可见性 }作用保证节点数据、链表结构的可见性val volatile一个线程修改 value其他线程立刻读到最新值next volatile线程追加新节点、修改链表指针其他遍历线程立刻感知链表变化核心价值支撑get() 无锁读取全程不加锁依靠 volatile 可见性拿到最新数据并发读性能极高。2.3 补充数组格子可见性Unsafe 兜底table 的 volatile 不管数组内部元素修改所以 JDK 底层通过三个 Unsafe 方法实现数组桶位的 volatile 读写tabAtvolatile 读桶头数据casTabAtCAS 无锁更新桶位setTabAtvolatile 写桶位数据三、CAS 无锁机制空桶写入专属3.1 核心定位CAS 是无锁乐观操作不是加锁适用唯一场景桶位为 null空桶// 如果当前桶为空CAS 尝试写入新节点 casTabAt(tab, i, null, new Node(hash, key, value, null));3.2 执行逻辑多线程同时写入同一个空桶CAS 比较内存值预期是 null 才写入只有一个线程成功其余线程自旋重试空桶场景无锁竞争性能极致避免了无脑加锁。四、synchronized 细粒度锁冲突场景核心保障当桶位已有数据链表/红黑树CAS 无法解决并发冲突启用 synchronized 互斥锁。4.1 锁对象核心规则全网最清晰总结链表桶锁「桶头普通 Node 节点」红黑树桶锁「桶头 TreeBin 对象」❌ 不锁链表所有节点、❌ 不锁 TreeNode、❌ 不锁数组4.2 如何实现锁住整条桶数据并不是语法上锁了整条链表/红黑树而是并发约定所有线程修改同一个桶的数据必须先竞争桶头锁同一时刻只有一个线程能修改该桶从而保证整条链表/红黑树的线程安全。4.3 锁粒度优势不同桶互不阻塞支持最大并发废弃 JDK1.7 笨重的 Segment 分段锁JDK1.8 对 synchronized 做了大量优化偏向锁/轻量级锁性能远超 ReentrantLock五、并发扩容机制兜底线程安全CHM 扩容不会阻塞所有线程支持多线程协助扩容是高并发核心亮点。5.1 核心流程达到扩容阈值新建 nextTable 新数组原桶正在迁移时标记为ForwardingNode其他线程写入时发现桶是 ForwardingNode先协助扩容迁移完成再写入全部迁移完毕执行table nextTablevolatile 全局可见彻底解决了 HashMap 扩容死循环、数据丢失问题。六、完整 put 执行流程串联所有机制判断数组是否未初始化CAS 初始化数组volatile 保证数组引用可见计算 hash 定位桶下标通过 tabAt volatile 读获取最新桶头桶为空CAS 无锁写入新节点桶正在扩容协助扩容后再写入桶已有数据synchronized 锁桶头链表遍历覆盖/追加节点依靠 node val/next volatile 保证可见性链表长度≥8 且数组≥64转为红黑树更新元素数量判断是否触发扩容七、最终总结可直接背诵、发博客收尾JDK1.8 ConcurrentHashMap 依靠三层可见性 无锁CAS 细粒度锁 并发扩容全方位保证线程安全volatile 两层可见性table 数组引用保证扩容切换全局可见Node 的 val、next 保证节点数据和链表结构实时可见支撑无锁读。CAS 无锁写入空桶场景乐观写入无锁高并发避免多余锁竞争。synchronized 细粒度互斥冲突场景锁桶头Node/TreeBin仅阻塞同桶线程最大化并发性能。并发扩容机制多线程协助迁移扩容不阻塞读写彻底解决并发扩容数据异常问题。相比 JDK1.7 分段锁锁粒度更细、并发度更高、读写性能更优是 Java 高并发场景下的标准键值存储方案。注部分内容可能由 AI 生成