做过几年 Java 后端面试官，也带过不少刚毕业的校招生，HashMap 这套题基本是每次技术面都要碰一遍的。很多候选人背得出“数组加链表加红黑树”这个标准答案，但问到为什么负载因子是 0.75、为什么容量是 2 的幂、为什么并发扩容会丢数据，就慢慢答不上来了。这篇文章不打算把源码贴满全篇，而是把 HashMap 面试题背后真正该搞懂的原理、参数来源和避坑经验拆开讲清楚。不管你是准备校招、社招，还是在维护老项目时被 HashMap 坑过，这篇都能帮你在下一次提到 HashMap 底层实现原理时，答得既准又有深度。
1. 先搞懂 HashMap 在解决什么问题：整体设计与思路拆解
1.1 为什么需要 HashMap：数组的随机访问和链表的灵活插入之间找个平衡
先聊一个很基础但容易被忽略的问题：HashMap 到底解决的是什么痛点。在 Java 里，如果你要把一批对象存起来并且能快速按 key 取到，最朴素的方案是用数组。数组一旦建好，按下标访问就是 O(1)，这个速度非常理想。但数组的问题是，你要知道 key 对应的下标。比如你要存一批用户信息，想按 userId 查，那可以直接用 userId 当下标，可现实中 userId 未必是连续整数，可能是字符串、可能是 Long 但中间有空洞，直接当下标，数组会稀疏得不成样子。
那换个思路，用链表。链表插入删除灵活，但查找只能从头遍历，数据一多就退化到 O(n)。HashMap 的思路就是这两者的结合：把 key 通过 hash 函数算成一个整数，再用这个整数定位到数组的某个桶（bucket），同一个桶里的冲突元素再用链表组织起来。这样一来，绝大多数情况下一个桶里只有一个元素，查询一次数组访问就命中；就算发生冲突，只要冲突不严重，链表也很短，性能依然可控。这就是“数组 + 链表”的核心设计动机，后面引入红黑树，也只是为了兜底极端冲突场景。
1.2 核心结构是散列表：从散列函数到冲突处理
HashMap 本质上是一种散列表实现。散列表的关键在于散列函数，Java 里每个对象都有 hashCode()，HashMap 就是拿这个 hashCode 来定位桶位。不过这里有个细节：hashCode 是 int 类型，范围有 2 的 32 次方那么大，而 HashMap 的数组初始容量只有 16，直接拿 hashCode 去映射到桶，肯定要对数组长度取模。取模运算涉及到一点，后面我会专门讲为什么 HashMap 用位运算替代取模。
冲突处理是散列表绕不开的话题。常见的方案有开放寻址法和链地址法。Java 的 HashMap 用的是链地址法，也叫拉链法，意思是：当多个 key 散列到同一个桶时，它们不互相挤占位置，而是在桶下面挂一条链表。链地址法实现简单，插入时直接挂到链表尾部，删除时从链表摘掉节点，对负载因子的容忍度也比开放寻址高。这也是面试常问“为什么用链表法而不是开放寻址法”的切入点，核心原因就是链表法对哈希冲突的连锁反应不敏感，最坏情况只是链表变长，而开放寻址法一旦发生聚集，后续插入和查询都可能触发一连串探测。
1.3 JDK 1.7 到 1.8 的演进：红黑树、尾插法和扰动函数的优化
很多八股文喜欢列 JDK 1.7 和 1.8 的区别，但如果你了解了设计动机，这些改动就很顺理成章。JDK 1.8 最核心的改动有三个：第一，链表长度超过阈值时转红黑树；第二，插入方式从头插法改成尾插法；第三，hash 扰动函数从四次位运算缩减成一次异或。
头插法改尾插法，初衷是优化插入效率。旧版本头插法不需要遍历链表就能把新节点插到头部，但代价是扩容并发时容易形成环形链表，导致 get 操作死循环 CPU 飙高。JDK 1.8 改成尾插法后，虽然插入时需要遍历链表到尾部，但在高并发场景下没有环的问题了。注意，这不代表 JDK 1.8 就线程安全了，丢数据的问题还是存在，这个后面专门说。红黑树的引入则是为了对抗恶意哈希碰撞或者极端的 hashCode 分布，把一个桶里的链表长度从 O(n) 查找优化到 O(log n)。这三处改动的共同逻辑就是：让常数级性能更稳，让退化场景不至于彻底失控。
2. 底层实现原理拆解：哈希碰撞、扰动函数与寻址公式
2.1 扰动函数到底在扰动什么：h ^ (h >>> 16)
HashMap 里计算 key 的 hash 值和直接调用 hashCode() 是有区别的。源码里有一行经典代码：
static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); }这就是所谓的扰动函数。为什么要拿 hashCode 的高 16 位和低 16 位做异或？一个很容易被忽略的事实是：HashMap 的桶位下标是用容量 n 和 hash 值做与运算算出来的，也就是 (n - 1) & hash。当 n 比较小时，比如默认容量 16，n - 1 的二进制是 1111，只有低 4 位参与运算，也就是说 hash 值的高 28 位完全白费了。如果两个对象的 hashCode 在高位不同、低位恰好相同，它们就会定位到同一个桶，产生不必要的碰撞。
把高 16 位和低 16 位异或，相当于把高位的信息“搅拌”到低位里去。这样即便数组容量很小，高位差异也能通过这种方式影响到最终桶位。这个操作叫扰动，名字很形象，就是让低位不再是单纯的低位，而是混合了高位信息。JDK 1.7 里扰动函数的位运算更多，要连续右移多次，JDK 1.8 精简成一次异或，因为作者经过测试认为一次右移异或的碰撞率已经足够低，同时性能更好。这里的取舍逻辑面试官非常喜欢听。
2.2 为什么用 (n - 1) & hash，而不是 hash % n
定位桶位时，HashMap 用的是位运算：
first = tab[(n - 1) & hash]这里的关键前提是 n 必须是 2 的幂。如果 n = 16，n - 1 的二进制是 1111，那么 (n - 1) & hash 的结果就取决于 hash 的后 4 位，取值范围 0 到 15，正好和固定容量对上。从数学角度讲，当 n 是 2 的幂时，(n - 1) & hash 等价于 hash % n，但位运算比取模快得多。这个优化在 hot path 上很重要，因为 HashMap 的每一次 get、put 都要做一次桶位定位，如果能省掉一次取模运算，整体吞吐就能上去。
坑点在于：一旦容量不是 2 的幂，(n - 1) & hash 的分布就会不均匀，比如 n = 15，n - 1 = 1110，最低位是 0，导致所有奇数下标永远不被命中，一半的桶浪费掉。这也是为什么 HashMap 的扩容必须严格保持容量为 2 的幂，也是构造方法里你传一个“奇怪”的初始容量，它也会自动帮你纠正的原因。
2.3 哈希碰撞怎么处理：链表法的工作原理与退化风险
提到哈希碰撞，就要说到链表法的工作方式。put 一个 key-value 的时候，流程大致是这样的：先计算 key 的 hash，再用 (n - 1) & hash 定位到桶，如果桶为空，直接放一个新节点；如果桶非空，遍历桶里的链表，逐个用 equals 比较 key，找到相同 key 就替换 value，找不到就在链表尾部追加新节点。
链表法的好处是冲突处理简单、插入不需要探测，但坏处也很明显：如果很多 key 都散列到同一个桶，链表就会越来越长。假设有 1000 个 key 全部撞进一个桶，那么 get 一个不存在的 key 最坏要比较 1000 次，从理想的 O(1) 直接退化到 O(n)。这就是所谓的最坏情况。平时开发时不太容易遇到，但在恶意输入场景下是真实的攻击面，比如有人构造大量 hashCode 相同的字符串，把 HashMap 的数据结构从散列表拖成链表，再配合频繁查询就能拖垮服务。红黑树的引入主要就是针对这个退化风险。
2.4 红黑树化：为什么树化阈值是 8，为什么反树化阈值是 6
JDK 1.8 中，当一个桶的链表长度超过 8 时会转成红黑树，但有条件：数组容量不能小于 64。如果容量还没到 64，即便链表长度到了 8，会优先扩容而不是直接树化，因为扩容后桶位会被打散，链表长度大概率降下来，没必要树化。这个细节很多人不知道，面试时说出来很加分。
为什么阈值是 8？源码注释里有一段基于泊松分布的计算。在负载因子 0.75、随机哈希函数正常工作的前提下，链表长度达到 8 的概率大约是千万分之六，非常罕见。也就是说，正常情况下链表长度不会超过 8，如果出现超过 8 的情况，大概率是 hashCode 设计有问题或者遭受恶意碰撞，此时树化才有意义。反树化阈值选 6 而不是 7，是为了留一个缓冲区间：如果阈值也是 8，那么一个桶在 8 和 9 之间反复变化时，就会不停地链表转树、树转链表，这个抖动成本很高。6 和 8 中间隔了个 7，从概率上就不会频繁触发转换。这种“留缓冲”的思路，在很多系统设计里都能看到。
3. 初始容量、负载因子与扩容机制：参数背后的计算逻辑
3.1 为什么容量必须是 2 的幂：位运算、扩容拆分和分布均匀性
前面提到，容量是 2 的幂才能用位运算替代取模。但它的作用不止于此。扩容的时候，旧数组容量 n 变成 2n，对同一个 hash 值来说，新桶位是 hash & (2n - 1)，在二进制上只比旧桶位多了一个 bit 的影响。这就带来一个很漂亮的特性：元素扩容后，要么留在原下标，要么移动到“原下标 + 旧容量”的位置，两种选择只取决于新增的那个 bit 是 0 还是 1。JDK 1.8 正是利用这一点，把扩容重排从每个元素重新计算下标，优化成通过高位 bit 分组、整段迁移，效率大幅提升。
反过来，如果容量不是 2 的幂，扩容后新旧下标的关系就没这么规整，只能逐个重新 hash 定位。所以“容量必须是 2 的幂”不是随便定的策略，而是贯穿了桶位定位、扩容拆分两个核心环节。面试时把这两点都讲出来，比只背“因为位运算快”要完整得多。
3.2 tableSizeFor 的位运算魔法：怎么把一个数变成不小于它的 2 的幂
HashMap 的构造方法允许你传一个预期的初始容量，但它内部并不会直接用这个值，而是调用 tableSizeFor 计算出“大于等于这个值的最小 2 的幂”。源码是这样：
static final int tableSizeFor(int cap) { int n = cap - 1; n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8; n |= n >>> 16; return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; }这段代码初看有点懵，原理其实不复杂。目标是把 n 的最高位以下的二进制位全部填充成 1，最后加 1 得到 2 的幂。例如 cap = 10，二进制 1010，cap - 1 是 1001，经过一连串右移异或后变成 1111，加 1 得到 16，正好是不小于 10 的最小 2 的幂。先把 cap 减 1，是为了处理 cap 本身就是 2 的幂的情况，否则会算成它的两倍，比如传 16 会得到 32，这就不符合预期了。
从这个细节能看出，HashMap 对容量的控制是非常讲究的。使用的时候，如果你能估算出数据量，建议直接指定初始容量，避免多次扩容。估算公式可以参考“数据量 / 0.75 + 1”，这样能保证插入数据时不需要触发 resize，减少一次全量 rehash 的开销。
3.3 负载因子 0.75 是怎么定出来的：时间与空间的折中
负载因子默认值是 0.75，这个数字不是拍脑袋定的。负载因子的含义是：当元素个数超过 capacity * loadFactor 时触发扩容。负载因子越大，比如 1，意味着数组更“满”才扩容，空间利用率高，但哈希碰撞概率增大，链表变长，查询性能下降。负载因子越小，比如 0.5，碰撞少、查询快，但空间浪费严重，频繁扩容也浪费性能。
0.75 是 JDK 作者在时间和空间成本之间取的一个平衡点。结合上面的泊松分布解释，在负载因子 0.75 的设定下，链表长度超过 8 的概率极低，能够和树化阈值 8 形成合理衔接。在绝大多数业务场景下，0.75 都是合理的默认值。如果确实能提前估计出数据量，可以手动指定容量，但不建议随意修改负载因子，除非你有非常充分的理由并且理解后果。面试官如果问“为什么不是 0.5 也不是 1”，把折中逻辑讲清楚就行。
3.4 扩容流程实战：旧桶拆分、高低位分组和 JDK 1.8 的优化
扩容流程用一句话概括：当元素个数超过阈值 threshold = capacity * loadFactor 时，把数组容量翻倍，然后重新分配所有节点。JDK 1.7 的做法是遍历每个节点，重新计算 hash 和下标，然后头插法插入新数组。JDK 1.8 利用了容量是 2 的幂的特性，做了一个很高效的优化。
因为新容量是旧容量的两倍，所以每个元素的新下标只可能是两个值之一：旧下标，或者旧下标 + 旧容量。判断方式就是看 hash 值在“旧容量对应的那个 bit 位”上是 0 还是 1。举个例子，旧容量 16，扩容到 32，就要看 hash 的第 5 位（二进制位权 16）是 0 还是 1。如果是 0，留在原桶；如果是 1，搬到原桶 + 16 的位置。
JDK 1.8 用两个链表分别串联“低位节点”和“高位节点”，最后分别挂到新数组的对应桶位。这样一次遍历就能把原链表拆成两段，不需要创建新节点，也不需要反复计算下标，效率比 JDK 1.7 高很多。同时也因为改用了尾插，扩容过程中不会产生链表反转，也就从机制上消除了并发扩容形成环的问题。不过这里一定要记住，这只是解决了“环”，并没有解决并发丢数据。
3.5 关于死循环问题：老版本 HashMap 的并发扩容事故
在很多老技术博客里，HashMap 并发扩容导致 CPU 100% 的问题非常出名。根因是 JDK 1.7 扩容时采用头插法，多线程同时扩容时，两个线程可能在同一个桶上互相覆盖 next 引用，造成链表形成环。之后任何对这个桶的 get 操作都会无限循环，CPU 飙升到 100%。这个问题在生产环境的严重性怎么强调都不为过，当年的老系统经常在这种事故上栽跟头。
JDK 1.8 改成尾插法后，链表顺序不再反转，形成环的概率大大降低，但并不意味着并发下就安全了，后面我会单独展开。面试时如果被问到死循环问题，记得点明这是 JDK 1.7 及以前的问题，JDK 1.8 通过尾插法修复了环的问题，但并发丢数据依旧存在。能答到这个层次，基本上这个知识点就算过关了。
4. 并发场景下 HashMap 的三大隐患与生产事故复盘
4.1 并发 put 为什么丢数据：赋值覆盖、size 不同步和 rehash 交错
先说明一点：HashMap 在任何 JDK 版本里都是线程不安全的。JDK 1.8 修复了死循环，但并发丢数据的问题依然存在。我见过的典型事故是多个线程同时 put 不存在的 key，结果最终 HashMap 里 size 只有 1，或者本来应该有 2 个 key，最后只有一个存在。
丢数据的原因可以从几个层面看。第一，put 操作中有一个“如果当前桶为空，直接赋予新节点”的步骤，两个线程同时判断桶为空，都创建了节点，后写的线程直接覆盖了先写的线程，一个 key 就悄无声息地消失了。第二，size 字段的增减不是原子的，多个线程同时 put 成功，但 size 可能只加了一次，导致后续判断扩容阈值时偏差，该扩容不扩容，哈希碰撞加剧。第三，扩容过程是“新建数组、迁移元素、替换引用”三步，并发下线程 A 在做迁移，线程 B 也在 put，B 拿到的是旧数组的引用，等 A 扩容完成后，B 写入的数据可能在旧数组中没被迁移，直接丢失。
由于这些都发生在并发状态下，问题复现有时候是偶发性的，日志里也看不出异常，排查难度很高。生产环境坚决不能拿 HashMap 当共享可变数据用，这是最基本的一条纪律。
4.2 modCount 和快速失败机制：遍历时为什么抛 ConcurrentModificationException
还有一个面试常考的点是 fail-fast 机制。HashMap 内部有个字段 modCount，记录结构性修改的次数。凡是 put 新 key、删除 key、扩容等改变结构的行为，都会让 modCount 加一。迭代器在创建时会保存一个 expectedModCount = modCount，每次 next() 都会检查两个值是否一致，不一致就抛 ConcurrentModificationException。
这个设计的本意是：在单线程迭代过程中，如果代码不小心修改了 HashMap，能在第一时间发现，而不是陷入未知状态。但在多线程场景下，即使另一个线程只是做了一次 put，如果恰好改变了结构，主线程的迭代也会立刻报错。换句话说，fail-fast 不是并发安全的保障，只是一个“尽早报错”的约定。日常写代码时，不要在遍历 HashMap 的过程中直接调用 remove，要利用 Iterator 的 remove 方法，它会把 expectedModCount 同步更新，避免踩这个异常。
4.3 并发场景的正确姿势：ConcurrentHashMap 和同步包装器的选择
如果确实需要并发的 Map，首选是 ConcurrentHashMap。JDK 1.8 的 ConcurrentHashMap 放弃了 JDK 1.7 的 Segment 分段锁，改用 CAS + synchronized 锁住桶的头节点，锁粒度更细，并发度更高。读操作大多数时候无锁，写操作只锁冲突的桶，性能和并发能力都优于直接给 HashMap 加全局锁。
如果项目里只是偶尔需要线程安全，也可以用 Collections.synchronizedMap(new HashMap<>())，它是给整个 Map 加一把全局锁，实现简单但并发性能差。要注意的是，Hashtable和 synchronizedMap 的锁范围是整个 Map，高并发下竞争激烈；而 ConcurrentHashMap 只在写同一个桶时才竞争锁，所以在高并发场景下优化效果非常明显。
选择时的经验：只读遍历场景多，用 ConcurrentHashMap；需要线程安全但读多写少，用 ConcurrentHashMap 也一样；如果还需要更复杂的原子复合操作，比如“不存在才插入”“存在才删除”，可以借助 ConcurrentHashMap 的 computeIfAbsent、compute 等方法，它们是原子性的，比自己判断后 put 要安全得多。
5. HashMap 面试 11 问速查：答题思路与参考话术
5.1 高频 11 问完整对照表
我整理了面试中最常问到的 11 个 HashMap 问题，每个问题配上核心答题要点。建议先自己回答一遍，再对照表格检查有没有漏点，这个方法比死记硬背效率高很多。
| 序号 | 面试题 | 核心答题要点 |
|---|---|---|
| 1 | HashMap 的底层数据结构是什么？ | JDK 1.8 是数组 + 链表 + 红黑树；普通情况链表，链表长度超过 8 且容量达到 64 时树化 |
| 2 | 为什么用红黑树而不用二叉搜索树？ | 二叉搜索树极端情况下会退化成链表，红黑树通过自平衡保证最坏时间复杂度为 O(log n) |
| 3 | 为什么树化阈值是 8，反树化是 6？ | 泊松分布下链表长度超过 8 的概率极低；6 和 8 之间留缓冲，避免频繁树化和反树化抖动 |
| 4 | 为什么容量必须是 2 的幂？ | 用位运算替代取模；扩容时可以通过高位 bit 分组，节点要么留在原下标，要么移到原下标加旧容量 |
| 5 | hash 方法里的 h ^ (h >>> 16) 有什么作用？ | 扰动函数，把高 16 位混合到低 16 位，让低位参与桶位计算时也包含高位信息，降低碰撞概率 |
| 6 | 为什么用 (n - 1) & hash 而不是 hash % n？ | n 为 2 的幂时两者等价，但位运算更快；且 n 非 2 的幂会导致部分桶永远不会被命中 |
| 7 | 负载因子为什么是 0.75？ | 时间和空间的折中；在 0.75 下链表长度超过 8 的概率极低，和树化阈值衔接合理 |
| 8 | JDK 1.8 对 HashMap 做了哪些优化？ | 红黑树化、尾插法替代头插法、扩容高低位分组、扰动函数简化 |
| 9 | HashMap 扩容的过程是什么？ | 容量翻倍，新建数组；JDK 1.8 按 hash 高位 bit 拆成高低位两个链表，分别挂到新数组对应桶位 |
| 10 | HashMap 为什么线程不安全？并发下会出现什么问题？ | 并发 put 覆盖丢数据、size 计数不准影响扩容、JDK 1.7 并发扩容还会形成环形链表导致死循环 |
| 11 | 为什么 ConcurrentHashMap 不允许 null，HashMap 却允许？ | HashMap 单线程可用 null 表示 key 不存在；并发下 null 值有歧义，无法区分“不存在”和“value 为 null”，ConcurrentHashMap 为了语义清晰直接禁掉 |
5.2 高分回答的三个技巧：先讲结论再讲原理、对比版本差异、落到工程实践
第一个技巧是分层回答。面试官问“HashMap 为什么线程不安全”时，不要只丢一句“因为 HashMap 没有锁”。更好的回答结构是：先给结论（并发场景存在数据丢失、扩容异常等风险），再讲具体机制（并发 put 的覆盖问题、size 非原子、扩容迁移的竞态条件），最后补一句“JDK 1.7 还可能出现环形链表导致死循环，JDK 1.8 修复了环的问题，但并发安全依然不能保证”。这样面试官一听就知道你不仅在背八股，是真的理解过。
第二个技巧是善用版本对比。HashMap 在 JDK 1.7 和 1.8 之间差异非常大，把差异当成主线来串知识点是一个天然的框架。面试官问底层实现原理时，你说“JDK 1.8 相比 1.7 做了三处核心优化”，然后把红黑树、尾插、扩容拆分逐一展开，逻辑线就很清晰。这样回答比单纯罗列知识点更有层次，也更容易在追问中说出细节。
第三个技巧是落到工程实践。面试官问完原理，大概率会追问“那你在实际项目里怎么用”。如果你能结合自己的项目说一句“我们当时预估数据量是 1 万左右，初始化时指定了容量 16384，避免扩容；并发场景统一用的 ConcurrentHashMap”，哪怕只是简单一句话，都会让回答更有说服力。面试官要的不只是一个记忆容器，而是一个能判断场景、能落地的工程师。
5.3 容易被追问的坑：hashCode 设计、不可变 key 和 equals 与 hashCode 的一致性
最后提醒几个容易翻车的点。第一个是 equals 和 hashCode 的一致性。HashMap 用 hashCode 定位桶，用 equals 判断 key 是否相等。如果你重写了 equals 但没有重写 hashCode，那么两个逻辑相等的对象 hashCode 不同，会被放进不同桶，get 时必然查不到。这个坑在自定义对象作为 key 时非常常见，务必两个一起重写。
第二个是 key 的不可变性。如果用一个对象做 key，放入 HashMap 后又修改了它的 hashCode 相关字段，哈希桶定位就会和之前不一致，后续 get 会找不到，甚至可能把数据留在旧的桶里，造成内存泄漏。String 和 Integer 这些不可变对象是天然的 key，自定义对象做 key 必须保证 hashCode 计算字段不可变，或者干脆用不可变包装。
第三个是 null 的处理。HashMap 允许 null key 和 null value，但在业务代码里，null key 很容易掩盖错误的 key 传入，建议在 put 之前显式校验，或者服务器端参数校验统一拦截。ConcurrentHashMap 则直接禁止 null key 和 null value，原因在表格第 11 条里已经提过，这里不再重复。这些点不算难，但都是实际编码里最常见的隐藏雷区，答出来会让面试官觉得你确实写过代码、踩过坑，而不是只会背书。
我个人的体会是，HashMap 这套面试题最考验人的地方不在背答案，而在能不能把参数和设计“算明白”。如果你能把 0.75、8、64、2 的幂这几个数字为什么这么定讲清楚，把 JDK 1.7 和 1.8 的差异讲清楚，再顺带说出并发下该用什么替代方案，基本上一整轮技术面的数据结构部分就稳了。面试结束后，我还建议你翻一翻 JDK 源码对照验证一下，不要只看二手总结。源码里的注释和实现逻辑，才是理解 HashMap 底层原理最好的老师。
