1. 面试官为什么总爱问这三个Map的区别
但凡你面过几家中高级Java岗位，就会发现一个规律：集合框架里的Map家族，几乎是绕不开的必考题。尤其是CurrentHashMap、HashMap、HashTable这三兄弟，面试官翻来覆去地问，候选人翻来覆去地背，但真正能答到点子上的人，说实话并不多。
我自己作为面试官面过不少人，也作为候选人和很多一线大厂的面试官聊过。这道题表面上考的是API差异，实际上考的是你对并发编程、数据结构演进、锁机制、内存可见性这些底层知识的综合理解。一个候选人如果只能说出“HashMap线程不安全、HashTable线程安全但慢、CurrentHashMap线程安全且快”，那基本就止步于初级评价了。真正拉开差距的，是你能不能讲清楚：为什么HashMap线程不安全？不安全体现在哪些具体场景？CurrentHashMap在JDK 1.7和1.8里分别是怎么实现线程安全的？为什么1.8要放弃分段锁？HashTable到底慢在哪里，它的锁粒度问题怎么理解？
这篇文章我打算把这道题彻底拆开讲透。不管你是正在准备面试的候选人，还是刚入行想搞懂集合框架的新人，或者已经工作几年但一直没系统梳理过这块知识的开发者，我都建议你耐心看完。我会从底层数据结构、线程安全机制、性能对比、版本演进、实际选型建议这几个维度，把这三个类的来龙去脉讲清楚，并且补充大量面试中真正会被追问的细节。
需要提前说明的是，本文涉及的源码分析基于主流JDK版本的常见实现，不同版本之间可能存在细微差异，但核心设计思想是一致的。另外，文中所有代码示例和场景都是我实际验证过的，你可以直接拿去复现。
2. 三者的核心定位与底层数据结构拆解
2.1 一句话定位三者的本质区别
先把结论摆出来，方便你建立整体认知：
- HashMap：单线程场景下的首选，基于哈希表实现，允许null键和null值，线程不安全，性能最高。
- HashTable：早期的遗留类，方法上几乎全部加了synchronized，线程安全但并发性能极差，基本已被淘汰。
- CurrentHashMap：为并发而生的哈希表，通过更细粒度的锁机制（1.7分段锁、1.8 CAS+synchronized）实现高并发下的线程安全，是多线程场景的标准选择。
这三者的关系，你可以这样理解：HashMap是基础款，HashTable是给基础款粗暴地套了一层大锁，而CurrentHashMap则是重新设计了一套更聪明的并发控制方案。理解了这个脉络，后面的细节就好展开了。
2.2 底层数据结构：从数组+链表到红黑树
HashMap的底层结构，在JDK 1.8之前是数组+链表，1.8之后变成了数组+链表+红黑树。这个变化非常关键，面试中经常被追问。
具体来说，HashMap内部维护一个Node数组（1.7叫Entry数组），每个数组位置我们称为一个“桶”（bucket）。当往Map里put元素时，先计算key的hash值，再通过扰动函数和位运算定位到数组下标。如果该位置已经有元素了，就发生了哈希冲突，新元素会以链表节点的形式挂在已有元素后面。
这里有个关键参数叫负载因子（loadFactor），默认0.75。当Map中元素数量超过“数组长度 × 负载因子”时，就会触发扩容（resize），数组长度翻倍。扩容是个很耗性能的操作，因为需要重新计算所有元素的位置。
JDK 1.8引入红黑树是为了解决一个极端问题：当哈希冲突严重时，链表会变得很长，查询时间复杂度从O(1)退化成O(n)。所以当链表长度超过8且数组长度大于等于64时，链表会转换为红黑树，查询复杂度优化到O(log n)。当红黑树节点数减少到6以下时，又会退化回链表。这个8和6的阈值设计，背后是泊松分布的统计学考量，面试时能提一句会很加分。
HashTable的数据结构和HashMap基本一致，也是数组+链表，但它没有红黑树的优化，而且初始容量和扩容规则不同——HashTable默认初始容量是11，扩容是2n+1，而HashMap默认是16，扩容是2n。这个差异很多人不知道，但面试官如果问细节，答出来就是亮点。
CurrentHashMap在JDK 1.7和1.8的结构差异很大。1.7是Segment数组+HashEntry数组+链表，每个Segment本质上是一个小型的HashMap，继承了ReentrantLock。1.8则抛弃了Segment，改成和HashMap类似的Node数组+链表+红黑树，但加上了CAS和synchronized来保证并发安全。
2.3 为什么HashMap线程不安全：三个致命场景
很多人只知道“HashMap线程不安全”这个结论，但说不出具体怎么个不安全法。我给你拆三个真实会出问题的场景，这些在面试中讲出来，面试官会明显感觉到你是真懂。
场景一：put操作导致数据覆盖。假设两个线程同时put，它们计算出的数组下标相同，都发现该位置为空，于是都准备写入。线程A先写入后，线程B后写入，就会把A的数据覆盖掉。这是最直观的数据丢失。
场景二：扩容时的死循环（JDK 1.7）。这是最经典的坑。1.7的HashMap在扩容时，链表元素的转移采用的是头插法，在多线程并发扩容的情况下，可能形成环形链表。一旦形成环，后续get操作就会陷入死循环，CPU直接飙到100%。这个问题在1.8里通过改成尾插法得到了修复，但1.8依然存在数据覆盖等其他并发问题，所以依然不安全。
场景三：size计数不准。HashMap的size字段是普通int变量，多线程并发put时，size的自增不是原子操作，最终结果会小于实际插入的元素数量。
注意：JDK 1.8虽然修复了死循环问题，但绝不意味着HashMap可以用于并发场景。数据覆盖、size不准这些问题依然存在，该用CurrentHashMap的地方千万别偷懒。
3. 线程安全机制深度对比：锁的粒度决定性能
3.1 HashTable的全局锁为什么慢
HashTable的线程安全实现方式非常粗暴：几乎所有公开方法都加了synchronized关键字，包括get、put、remove、size等等。这意味着什么？意味着同一时刻，只有一个线程能操作整个HashTable，其他线程全部阻塞等待。
你可以把HashTable想象成一个只有一个入口的超市，不管你是来买东西还是来结账，都得排队，一次只能进一个人。这种全局锁的粒度太粗了，在并发量稍高的场景下，性能会急剧下降。而且你会发现，get操作其实是不修改数据的，理论上可以并发读，但HashTable连get都锁了，这就造成了大量无谓的等待。
实测数据上，在4线程并发读写的场景下，HashTable的吞吐量往往只有CurrentHashMap的几分之一甚至更低。这也是为什么现在几乎没人用HashTable了，它更多是作为面试考点和Java集合框架历史的一部分存在。
3.2 CurrentHashMap 1.7的分段锁设计
JDK 1.7的CurrentHashMap引入了**分段锁（Segment）**的概念，这是一个非常巧妙的设计。它把整个哈希表分成若干个Segment（默认16个），每个Segment独立加锁。这样，不同Segment上的操作可以并发进行，锁的粒度从“整个表”细化到了“一个段”。
具体来说，Segment继承自ReentrantLock，每个Segment内部维护一个HashEntry数组。当线程要put元素时，先根据key的hash定位到具体的Segment，然后只锁住这个Segment，其他Segment不受影响。理论上，默认16个Segment的情况下，最多可以支持16个线程并发写入。
这个设计比HashTable的全局锁进步了一大截，但它也有局限：内存开销更大（每个Segment都要维护独立的结构），而且并发度受Segment数量限制。如果Segment数量固定为16，那并发度上限就是16，无法动态扩展。
3.3 CurrentHashMap 1.8的CAS+synchronized方案
JDK 1.8对CurrentHashMap做了大改，彻底抛弃了Segment分段锁，改用CAS + synchronized的组合方案。这个变化背后的逻辑是：分段锁虽然比全局锁好，但内存开销大、并发度受限，而CAS这种乐观锁在冲突较少时性能更优。
1.8的具体做法是这样的：
- put操作：如果目标桶为空，直接用CAS尝试写入，不需要加锁，这是最理想的情况。如果桶不为空，则用synchronized锁住该桶的头节点，然后进行链表或红黑树的插入操作。注意，锁的粒度已经细化到了单个桶，比Segment还要细。
- get操作：完全不加锁，因为Node的val和next都用volatile修饰，保证了内存可见性。
- 扩容操作：支持多线程协助扩容，通过ForwardingNode标记正在迁移的桶，其他线程遇到时可以参与迁移，提升扩容效率。
这个设计的精妙之处在于：大部分put操作在桶为空时是无锁的，只有发生哈希冲突时才需要加锁，而且锁的只是一个桶。在高并发且数据分布均匀的场景下，性能提升非常明显。
3.4 三种锁机制的性能对比
为了让你更直观地理解，我整理了一张对比表：
| 对比维度 | HashTable | CurrentHashMap 1.7 | CurrentHashMap 1.8 |
|---|---|---|---|
| 锁类型 | synchronized全局锁 | ReentrantLock分段锁 | CAS + synchronized |
| 锁粒度 | 整个哈希表 | 单个Segment | 单个桶（头节点） |
| 并发度 | 1 | Segment数量（默认16） | 桶数量（可动态扩展） |
| 读操作 | 加锁 | 加锁（部分） | 不加锁 |
| 内存开销 | 小 | 较大 | 中等 |
| 扩容方式 | 单线程 | 单线程（段内） | 多线程协助 |
从这张表可以清楚看出，锁的粒度越来越细，并发度越来越高，这就是CurrentHashMap性能优势的根本来源。
实操心得：面试时如果被问到“为什么1.8要放弃分段锁”，你可以从三个角度回答——一是分段锁内存开销大，二是并发度受Segment数量限制无法动态扩展，三是CAS在低冲突场景下比加锁更轻量。这三点答全，基本就满分了。
4. 源码级实操：关键方法的执行流程
4.1 HashMap的put流程完整拆解
理解HashMap的put流程，是掌握整个哈希表机制的基础。我把1.8版本的put流程拆成几个关键步骤：
- 计算hash值：调用
hash(key)方法，内部是(h = key.hashCode()) ^ (h >>> 16)。这个扰动函数的作用是让高位也参与运算，减少哈希冲突。 - 定位数组下标：用
(n - 1) & hash计算，其中n是数组长度。因为n是2的幂，所以这个位运算等价于取模，但效率更高。 - 判断桶是否为空：如果为空，直接新建Node放入。
- 处理哈希冲突：如果桶不为空，分三种情况——如果是红黑树节点，走红黑树插入；如果是链表，遍历链表，如果找到相同key就覆盖value，否则尾插到链表末尾。
- 判断是否需要树化：链表长度达到8且数组长度达到64时，转为红黑树。
- 判断是否需要扩容：size超过阈值时调用resize。
这里有个细节值得注意：为什么数组长度必须是2的幂？因为只有2的幂，(n-1) & hash才能等价于hash % n，同时保证元素分布均匀。如果n不是2的幂，位运算的结果会不均匀，导致某些桶特别拥挤。这也是为什么HashMap的构造方法里，即使你传入的初始容量不是2的幂，它也会通过tableSizeFor方法向上取整到最近的2的幂。
4.2 CurrentHashMap的put流程与CAS应用
CurrentHashMap 1.8的put流程比HashMap复杂，因为要处理并发。核心流程如下：
// 伪代码示意，帮助理解流程 final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); int binCount = 0; for (Node<K,V>[] tab = table;;) { Node<K,V> f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // 初始化，CAS控制 else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 桶为空，CAS写入，失败则自旋重试 if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null))) break; } else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); // 协助扩容 else { V oldVal = null; synchronized (f) { // 锁住头节点 // 链表或红黑树插入逻辑 } } } addCount(1L, binCount); // 更新size，可能触发扩容 return null; }从这段流程可以看出几个关键点：桶为空时用CAS无锁写入，这是性能优化的核心；桶不为空时用synchronized锁头节点，保证冲突处理的线程安全；遇到ForwardingNode时协助扩容，提升整体效率。
4.3 扩容机制的差异与性能影响
扩容是哈希表性能的关键节点。HashMap的扩容是单线程的，需要重新计算所有元素的位置，数据量大时会有明显的停顿。CurrentHashMap 1.8支持多线程协助扩容，当线程发现当前桶是ForwardingNode时，会加入迁移工作，把扩容的压力分摊到多个线程上。
具体来说，CurrentHashMap在扩容时会维护一个transferIndex，多个线程通过CAS竞争领取迁移任务，每个线程负责迁移一部分桶。迁移完成的桶会被标记为ForwardingNode，其他线程的get操作遇到它会转发到新表。这个设计大大缩短了扩容的停顿时间。
注意：虽然CurrentHashMap支持并发扩容，但扩容依然是有开销的。如果你的场景能预估数据量，建议在创建时就指定合适的初始容量，避免频繁扩容。计算公式是：
初始容量 = 预估元素数量 / 0.75 + 1，然后向上取整到2的幂。
5. 高频面试追问与避坑指南
5.1 为什么CurrentHashMap不允许null键和null值
这是个高频追问。HashMap是允许null键和null值的，但CurrentHashMap明确禁止，源码里put时会直接抛NullPointerException。为什么？
核心原因是并发场景下的二义性。假设CurrentHashMap允许null值，那么当你调用get(key)返回null时，你无法区分这个null是“key不存在”还是“key存在但value为null”。在单线程的HashMap里，你可以用containsKey来区分，但在并发场景下，你调用containsKey和get之间，其他线程可能已经修改了Map，导致判断失效。所以CurrentHashMap干脆禁止null，从根源上消除这个歧义。
HashTable也不允许null键和null值，原因类似，虽然它是单线程加锁的，但设计上沿用了这个约束。
5.2 HashMap的初始容量和负载因子怎么设置
很多人创建HashMap时直接用默认构造，这在数据量可预估的场景下其实不够好。默认初始容量16、负载因子0.75，意味着元素超过12个就会扩容。如果你明确知道要存1000个元素，直接new HashMap<>(2048)比默认构造要高效得多，能避免多次扩容。
负载因子0.75是个折中值：太高（比如1.0）会减少空间浪费但增加哈希冲突，太低（比如0.5）会减少冲突但浪费空间。除非有特殊需求，一般不建议改。如果确实要改，需要理解它影响的是空间和时间的权衡。
5.3 常见问题速查表
我把面试和实操中经常遇到的问题整理成一张表，方便你快速查阅：
| 问题 | 原因 | 解决/回答思路 |
|---|---|---|
| HashMap并发put数据丢失 | 多线程同时写入同一桶 | 改用CurrentHashMap |
| JDK 1.7 HashMap扩容死循环 | 头插法导致环形链表 | 升级到1.8或改用CurrentHashMap |
| CurrentHashMap size不精确 | 并发下计数是估算值 | 用mappingCount()，接受近似值 |
| HashTable性能差 | 全局synchronized锁 | 改用CurrentHashMap |
| 红黑树转换阈值为什么是8 | 泊松分布统计结果 | 冲突概率低于千万分之一 |
| CurrentHashMap迭代器弱一致 | 不阻塞其他线程修改 | 接受弱一致性，或用其他方案 |
5.4 独家避坑经验分享
最后分享几个我在实际开发和面试中总结的经验，这些是常规文档里不会写的：
第一，别在面试时只背结论。面试官问“三者区别”，如果你只答“线程安全、性能、null支持”这三点，大概率会被追问到答不上来。正确的策略是主动展开，比如讲HashMap时主动提1.8的红黑树优化和1.7的死循环问题，讲CurrentHashMap时主动提1.7到1.8的演进。主动输出信息，能掌握面试节奏。
第二，CurrentHashMap的复合操作不是原子的。这是个隐藏很深的坑。比如if (!map.containsKey(k)) map.put(k, v);这种“检查再操作”的复合逻辑，即使map本身线程安全，整体也不是原子的，依然可能出问题。正确做法是用putIfAbsent、computeIfAbsent这些原子方法。
第三，size()方法在并发下不可靠。CurrentHashMap的size()返回的是估算值，因为并发插入时计数可能不准。如果你需要精确计数，应该用mappingCount()，但它返回的也是近似值。真正需要精确计数的场景，得自己额外维护计数器。
第四，迭代器的弱一致性要理解。CurrentHashMap的迭代器是弱一致的，迭代过程中其他线程的修改可能反映也可能不反映，但不会抛ConcurrentModificationException。这和HashMap的fail-fast机制完全不同，使用时要有心理预期。
第五，选型要看场景而不是盲目追新。单线程场景用HashMap性能最好，没必要上CurrentHashMap。只有真正存在并发读写时才需要CurrentHashMap。我见过有人为了“保险”把所有Map都换成CurrentHashMap，结果单线程场景下性能反而下降，这是没必要的。
关于这三个Map的对比，其实还有很多可以深挖的点，比如CurrentHashMap的计数机制LongAdder、红黑树的旋转细节、hash扰动函数的数学原理等等。但把上面这些吃透，应对绝大多数面试和实际开发已经足够了。我个人在实际项目中的体会是，理解这些底层机制最大的价值不在于面试，而在于你写并发代码时，脑子里能清楚地知道每一步操作背后的代价和风险，从而做出更合理的选型。
