深入图解 ConcurrentHashMap 底层实现：从 JDK1.7 到 1.8 的史诗级蜕变
导语：
在 Java 面试中，如果有哪一个集合类能霸占 80% 的出场率，那绝对非ConcurrentHashMap莫属。大家都知道HashMap线程不安全，HashTable性能又太差。为了兼顾“性能”和“安全”，ConcurrentHashMap站了出来。
但这并不是最要命的，让无数开发者头疼的地方在于：从 JDK 1.7 到 JDK 1.8，它的底层数据结构发生了一次“史诗级”的颠覆。本篇文章，我们将拨开源码的迷雾，用最通俗的语言，带你彻底搞懂这两个版本的底层实现逻辑。
🎯 一、 前置知识：为什么要有 ConcurrentHashMap？
在单线程环境下，HashMap是无敌的。但是在多线程并发写入时，HashMap会出现不可预知的安全问题（特别是在 JDK 1.7 中，多线程扩容甚至会导致链表形成“死环”，让 CPU 飙升到 100%）。
如果为了安全直接换成HashTable，它粗暴地给整个方法加上了synchronized（相当于独占锁）。只要有一个线程在操作，别的线程全都在门外干等，性能极其低下。
为了解决这个问题，ConcurrentHashMap诞生了，它的终极目标就是：尽可能地缩小加锁的范围，让各个线程互不干扰地并发工作。
🏗️ 二、 JDK 1.7 的实现：经典经典的“分段锁”设计
在 JDK 1.7 时期，ConcurrentHashMap 的核心设计思想非常明确，叫做：分段锁（Segment）。
1. 核心底层结构
它的底层采用的是：Segment 数组+HashEntry 数组+链表的嵌套结构。
- 外层结构 (Segment 数组)：它首先将整个大 Map 拆分成了很多个小的子 Map，这些子 Map 被称为
Segment。默认情况下有 16 个 Segment。 - 内层结构 (HashEntry 数组 + 链表)：每一个
Segment里面，本质上就是一个小型的HashMap（数组+链表）。
2. 它是如何工作的？
当你想要向 Map 中 put 一个键值对时：
- 先做一次 Hash，定位到它属于哪一个
Segment。 - 再去获取这个
Segment的锁。 - 获取到锁之后，再做一次 Hash，定位到内部的
HashEntry数组的具体位置，挂到链表上。
💡小白通俗易懂解释：
JDK 1.7 的 ConcurrentHashMap 就像是一个拥有16 个独立房间的大仓库。HashTable是在仓库大门上挂了一把大锁，一次只能进去一个人。
而ConcurrentHashMap 1.7是在大门不设阻拦，给16 个房间的门上分别挂了一把锁。只要你们不去同一个房间放东西，大家就可以同时进去干活，理论上最高能支持 16 个人（线程）同时操作，互不影响！
🚀 三、 JDK 1.8 的蜕变：抛弃 Segment，向“数组+链表+红黑树”进化
虽然分段锁的设计很巧妙，但是 JDK 开发团队认为它还不够极致。在 JDK 1.8 中，整个架构被全面推翻重写！
1. 为什么抛弃了 Segment？
- 并发度受限：Segment 的数量一旦初始化就不能更改（默认 16），这意味着哪怕后面你的数据量达到百万级别，最高并发度依然只有 16。
- 内存开销大：外层 Segment 数组使得层级变深，每一个 Segment 都要维护一套各种指标参数，白白吃掉了很多堆内存。
- 查询效率不够高：极端情况下（发生严重的 Hash 冲突），所有的元素都挂在同一个长长的单向链表上，导致查询速度从
O(1)退化成非常慢的O(N)。
2. 1.8 的核心底层结构
抛弃了臃肿的Segment，JDK 1.8 把结构重新拍扁，直接回归了原汁原味的HashMap风格，采用了：Node 数组+单向链表+红黑树
- 扁平化：直接由一个巨大的
Node[] table撑起局面。 - 引入红黑树：这是最大的杀招。当某一层位置上的链表长度超过 8 且数组总长度超过 64时，链表会扭身一变，转化成极速的“红黑树”。
💡小白通俗易懂解释：
JDK 1.8 直接把 16 个小房间的隔离墙给拆了，变成了一个巨大的露天广场（Node数组），上面有无数个摊位。
如果大家都去不同的摊位，那是毫无阻碍的并发。
但如果某一个摊位生意太火爆，排队的人连成了一条长龙（链表太长），老板就会直接造一台高速电梯（红黑树），让你找货的速度从“一层层爬楼梯”变成了“极速直达”（查询复杂度从 O(N) 变成了 O(logN)）。
📊 四、 总结：从 1.7 到 1.8 的三大演进对比
| 维度 | JDK 1.7 | JDK 1.8 | 核心演进点与优势 |
|---|---|---|---|
| 整体数据结构 | Segment数组 + HashEntry数组 + 链表 | Node数组 + 链表 + 红黑树 | 结构被拍扁，取消了 Segment 的包裹，内存占用大幅下降。 |
| 极限查询性能 | 链表退化，最差 O(N) | 引入红黑树，最差 O(logN) | 解决了 Hash 严重冲突时，链表无限长导致的查询灾难。 |
| 最高并发粒度 | 受限于 Segment 数量（默认 16） | 受限于 Node 数组的长度 (极其庞大) | 彻底解放了并发能力的上限，数组有多长，就能支持多大的并发量。 |
下篇预告：我们在本文搞懂了它在不同时代下的数据结构模型。但在彻底取消了 Segment 分段锁的 1.8 中，它是究竟如何保证多线程安全的呢？请移步本专栏姊妹篇《揭秘 ConcurrentHashMap 并发安全的底层黑科技》。