莱夢1. 从一道面试题说起：HashMap到底在解决什么问题
前两天帮组里一个刚转Java的同事过简历，他信誓旦旦地说自己已经把HashMap源码背下来了。我随口问了句：“那你说说，为什么树化阈值是8而不是7或者9？”他愣了三秒，回了一句“源码里写的”。这种回答，熟悉吧？
这个场景其实特别典型。现在网上关于HashMap的八股文到处都是，大家背得滚瓜烂熟：“数组加链表加红黑树”“默认容量16，负载因子0.75”“扩容时重新散列”。但光背结论，不搞懂背后的权衡和设计逻辑，遇到稍微偏一点的问题就会露馅。这篇东西我整理了挺久，从源码逐行读到线上排查的经验，把HashMap真正值得搞清楚的那些点拆开讲明白。
先说一个核心认知：HashMap本质是一个面向随机读写的映射表容器。它解决的核心问题，是在key-value存储场景下，如何让插入、查找、删除的平均时间复杂度都做到O(1)。这个“平均”两个字很关键，底下会说为什么是平均而不是严格。它底层用到的数据结构是哈希表，通过对key计算哈希值来决定value落在哪个桶里，冲突了怎么办——这是所有哈希表实现都要面对的经典问题。
适合读这篇内容的，主要是这几类人：准备面试需要系统梳理HashMap底层原理的Java开发；日常写代码只用但没读过源码的使用者；以及排查线上CPU飙高、响应变慢时碰到疑似hash冲突或扩容问题的运维和开发。这篇文章的源码基于JDK 8，这是目前线上使用最广泛的版本，JDK 11和17的HashMap逻辑与JDK 8基本一致，后续我会提几个差异点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 对象布局与底层存储：数组、链表和红黑树到底怎么协同工作
2.1 Node节点的四个字段，藏着一个哈希表的全部秘密
打开JDK 8的HashMap源码，第一件值得看的东西就是它的静态内部类Node：
java复制static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
V value;
Node<K,V> next;
}
四个字段，每个都有讲究。hash存的是key经过扰动函数处理后的哈希值，注意它被声明为final，意思是节点一旦创建，它在桶数组中的位置就永远确定了。key也是final，因为key的哈希值决定了整个节点存储的位置，key一旦变化，这个节点就相当于放错了位置，再查就找不到了。value是普通字段，可以随时替换。next是指向下一个节点的引用，链表就是这么串起来的。
HashMap内部维护的核心字段则是这几个：
java复制transient Node<K,V>[] table; // 桶数组，首次使用时才初始化
transient int size; // 实际存储的键值对数量
int threshold; // 扩容阈值 = capacity * loadFactor
final float loadFactor; // 负载因子，默认0.75
transient int modCount; // 结构性修改次数，用于快速失败
这里有个小细节，transient关键字意味着table数组和size都不会被序列化，因为哈希表的内部布局完全取决于hashCode实现和容量大小，序列化后再反序列化时必须重新计算位置，直接序列化底层数组没有意义。
2.2 为什么是数组——O(1)查找的根本保证
所有哈希表的根都在数组上。数组最大的优势是支持随机访问：给定下标，直接在内存偏移计算中找到目标元素，时间复杂度O(1)。HashMap把key哈希后映射成一个数组下标，这个映射就是(n - 1) & hash，其中n是数组长度。
这就好比你去图书馆借书，馆员给了你一个分类编号，你根据编号直接走到对应书架，不需要一本一本地翻。理想情况下，每个key都对应一个不同的编号，一次就能找到。但现实是，编号可能会撞——这就是哈希冲突。
2.3 链表解决冲突，红黑树解决极端退化
当两个key哈希后映射到同一个桶时，HashMap怎么处理？拉链法。新节点直接追加到桶内链表的尾部。
链表方案最直接、实现最简单，插入只需O(1)（尾部追加），遍历查找则是线性扫描O(n)。当冲突数量少的时候，链表完全够用。但如果一个桶里挂了几百个节点，每次查找都是几百次比较，性能就崩了。这就是哈希碰撞攻击的经典攻击方式。
为防止这种极端情况，JDK 8引入了红黑树。当一个桶内的节点数达到TREEIFY_THRESHOLD = 8时，链表被转成红黑树，查找复杂度从O(n)降到O(log n)。红黑树是一种自平衡二叉查找树，保证最坏情况下树的高度在2 * log2(n+1)以内。
2.4 树化阈值为什么是8：泊松分布算出来的
源码注释里给了这么一段：
Because TreeNodes are about twice the size of regular nodes, we use them only when bins contain enough nodes to warrant use (see TREEIFY_THRESHOLD). And when they become too small (due to removal or resizing) they are converted back to plain bins. In usages with well-distributed user hashCodes, tree bins are rarely used. Ideally, under random hashCodes, the frequency of nodes in bins follows a Poisson distribution with a mean of about 0.5.
翻译成工程语言就是：在理想情况下（hashCode分布均匀），每个桶内的节点数服从参数λ≈0.5的泊松分布，达到8个节点的概率大约是0.00000006。也就是说，正常场景下你几乎不可能看到链表转树。一旦出现了，说明要么hash算法被刻意攻击，要么某个类的hashCode实现极其糟糕。
code复制λ = 0.5时，泊松分布概率：
P(0) ≈ 0.6065
P(1) ≈ 0.3033
P(2) ≈ 0.0758
P(3) ≈ 0.0126
P(4) ≈ 0.0016
P(5) ≈ 0.0002
P(6) ≈ 0.00002
P(7) ≈ 0.000001
P(8) ≈ 0.00000006
看到没，树化阈值取8不是拍脑袋定的，而是让“链表转树”这个事件在正常场景下几乎不可能触发，只有真正的极端情况才会走树化逻辑。
2.5 最小树化容量64：防止频繁扩容造成的折腾
还有一个容易被忽略的参数：MIN_TREEIFY_CAPACITY = 64。如果桶数组长度小于64，即使某个桶的链表长度超过8，HashMap也不会直接树化，而是先执行resize()扩容。为什么？
因为当桶数组容量还很小时，哈希冲突往往是因为容量不足造成的分布不均匀，而不是key的hashCode本身有问题。此时与其树化，不如把桶数组扩大一倍，让节点重新散列到更多桶里，冲突自然就缓解了。扩容的代价是一次性重排，但换来的是整张表的整体分布改善，比局部树化收益大得多。
2.6 红黑树节点TreeNode的内存代价
一个TreeNodes对象有7个字段：hash、key、value、next、parent、left、right、prev、red布尔值。普通Node只有4个字段。算下来TreeNode占用的内存大约是Node的两倍。所以源码注释里那句“TreeNodes are about twice the size of regular nodes”说得就是这个意思。
这也解释了为什么HashMap 会做双向转换：链表转树是为了查得快，树退化成链表是为了省内存和减少维护成本。当树中节点数因删除或扩容降到UNTREEIFY_THRESHOLD = 6时，红黑树转回链表。为什么转回阈值是6而不是8？这是为了留缓冲，防止在8附近频繁地树化和退化来回切换，造成“抖振”。
3. hash方法的进化史：为什么hash值要右移16位再异或
3.1 一段被吐槽无数次的代码
这是JDK 8里的hash方法：
java复制static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
如果key是null，返回0。如果key不为null，取key.hashCode()赋值给h，然后把h右移16位，再跟原来的h做异或。就这么两行，很多人不理解为什么绕这么一圈。
看不懂这段代码，是因为还不清楚后面数组下标是怎么算的。HashMap在确定key对应哪个桶时，用的不是hash % n这种取模运算，而是：
java复制i = (n - 1) & hash
其中n是桶数组长度。这个公式成立的前提是，n必须是2的幂。为什么是2的幂？因为n - 1的二进制表示就是低位全为1的掩码，按位与操作相当于只取hash值的低n-1个二进制位，效果等同于取模。而位运算比取模快一个数量级。
3.2 高16位和低16位的博弈
问题来了。当n比较小的时候（比如默认容量16），n - 1是15，二进制是0000...00001111。此时(n - 1) & hash实际只用了hash的低4位，高28位信息全部丢了。
如果两个key的hashCode在高位不同、低位恰好一样，它们就会映射到同一个桶，造成无谓的碰撞。hash方法的本质，就是把高位信息通过异或混合到低位，让低位的熵更大，分布更均匀。
h >>> 16是无符号右移16位，把高16位搬到低位区；然后跟原值异或，高16位和低16位互相影响。由于异或操作的特点是“相同为0、不同为1”，整体熵不会下降。这样一来，即使n很小，计算下标时也能用上高位的分布特征。
这个设计在JDK 7叫“扰动函数”，当时更复杂，做了4次异或和位移。JDK 8的作者认为4次太多了，一次就够了。JDK 7的代码长这样：
java复制static int hash(int h) {
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
3.3 为什么数组长度必须是2的幂
不只是为了位运算快。更关键的原因是，HashMap扩容时有一个非常精巧的优化：节点在新数组中的位置，要么和原来一样，要么在原来基础上偏移oldCap。这个结论依赖n是2的幂，后面扩容章节再细说。
如果你自己创建HashMap时传了一个不是2的幂的初始容量，比如new HashMap<>(13)，HashMap内部会调用tableSizeFor这个方法：
java复制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;
}
这一串位移和或运算的结果，是把cap变成大于等于它的最小2的幂。传13，最终table容量是16；传17，容量是32。这个方法的原理就是通过右移和或运算，把最高位1后面的所有位都变成1，最后加1得到2的幂。
注意：capacity是桶数组真正初始化的长度，不是你传给构造函数的数值。
threshold的初始值是tableSizeFor后的结果，等第一次put触发resize后才变成capacity * loadFactor。
4. put流程全拆解：从hash定位到树化决策
4.1 putVal方法逐段读
put方法本身只做了一层包装：
java复制public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
真正的逻辑全在putVal里。我把它拆成几个阶段来看。
第一阶段：初始化检查。
java复制if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
第一次put时，table还是null，直接调用resize()初始化桶数组，默认容量16。HashMap采用的是懒加载策略，不在构造函数里分配数组，这么做是为了避免创建了对象但一直没数据时白白占内存。
第二阶段：定位桶位置，如果桶是空的，直接放新节点：
java复制if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
这是最理想的情况，没有哈希冲突，每个操作都是常数级。实际生产环境中，绝大多数put操作走的都是这个分支，这也是HashMap能保持O(1)的核心原因。
第三阶段：哈希冲突处理。桶不为空，说明有节点了：
java复制if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
e = p; // 第一个节点就是目标key，直接覆盖
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); // 树节点走树插入
else {
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null); // 追加到链表尾部
if (binCount >= TREEIFY_THRESHOLD - 1) // 链表长度达到8
treeifyBin(tab, hash);
break;
}
if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
break; // 找到相同key，跳出循环
p = e;
}
}
注意几个点。第一，JDK 8是尾插法，新节点追加到链表尾部，而JDK 7是头插法，新节点插到链表头部。这个区别直接决定了并发环境下扩容是否会出现死循环。第二，每插入一个节点都会检查binCount >= TREEIFY_THRESHOLD - 1，注意binCount从0开始计数，所以链表长度达到8时触发树化。第三，如果链表中已经有相同key的节点，不改变结构，只替换value。
第四阶段：完成put操作后：
java复制if (e != null) {
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
如果存在相同key，返回旧值，然后触发afterNodeAccess回调。这个方法是给LinkedHashMap留的钩子，普通HashMap里是空实现。
第五阶段：新增节点后的结构变化处理：
java复制++modCount;
if (++size > threshold)
resize();
afterNodeInsertion(evict);
modCount用于迭代器的快速失败机制，只要HashMap的结构发生修改，modCount就加一。如果size超过threshold，触发扩容。afterNodeInsertion同样是LinkedHashMap的钩子。
4.2 为什么JDK 8要改成尾插法
JDK 7的头插法在扩容时会倒置链表顺序，并发环境下两个线程同时扩容可能形成环形链表，导致get死循环。这个坑曾经让无数人线上半夜爬起来排查。
JDK 8改成尾插法后，链表顺序不再反转。但注意，死循环问题在JDK 8并没有彻底消失，只是概率大幅降低了。并发环境下HashMap仍然可能丢数据，甚至在某些极端情况下依然会出现环。永远不要指望HashMap在并发场景下安全，并发请用ConcurrentHashMap。这是原则问题，不讨论例外。
4.3 treeifyBin：树化的完整条件
上面代码里树化调的是treeifyBin方法，这个方法内部还做了一层检查：
java复制final void treeifyBin(Node<K,V>[] tab, int hash) {
int n, index; Node<K,V> e;
if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
resize();
else if ((e = tab[index = (n - 1) & hash]) != null) {
TreeNode<K,V> hd = null, tl = null;
// 把链表节点转成TreeNode，并构建双向链表
do {
TreeNode<K,V> p = replacementTreeNode(e, null);
if (tl == null)
hd = p;
else {
p.prev = tl;
tl.next = p;
}
tl = p;
} while ((e = e.next) != null);
// 调用TreeNode.treeify真正构建红黑树
if ((tab[index] = hd) != null)
hd.treeify(tab);
}
}
看到没有，树化前必须检查桶数组长度是否达到MIN_TREEIFY_CAPACITY（64）。如果没到64，先扩容而不是树化。这样设计的理由是：在数组容量较小时，链表之所以长，很可能是容量不足导致的位置拥挤，扩容能让原本挤在一个桶里的节点重新分布，通常扩容后链表长度就降下来了，根本不值得动用红黑树。
树化过程有个很容易忽视的细节：链表节点先转成TreeNode，同时维持着prev和next的双向关系，然后再通过treeify方法构建红黑树。TreeNode本身保留了链表的next引用，这就是为什么后面红黑树退化回链表时可以直接顺着next指针遍历，不需要重新用中序遍历。
5. get流程与TreeNode：查找性能的边界条件
5.1 getNode的完整路径
get方法的源码相对简单：
java复制public V get(Object key) {
Node<K,V> e;
return (e = getNode(hash(key), key)) == null ? null : e.value;
}
核心逻辑在getNode：
java复制final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
if (first.hash == hash && ((k = first.key) == key || (key != null && key.equals(k))))
return first; // 桶的第一个节点就是目标
if ((e = first.next) != null) {
if (first instanceof TreeNode)
return ((TreeNode<K,V>)first).getTreeNode(hash, key); // 走红黑树查找
do {
if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
return e; // 遍历链表查找
} while ((e = e.next) != null);
}
}
return null; // 桶数组为空或目标不存在
}
流程很清晰：先检查table非空、数组非空、桶位置非空，然后比较首节点。这里有个性能优化的细节，比较key时先比hash再比equals：e.hash == hash && ...。hash是int比较，速度极快，大概率能直接过滤掉不匹配的节点，只有hash相等的才需要调用equals做更精确的比较。设计上是用hash做前置筛选，减少equals的调用次数。
5.2 TreeNode查找为什么能做到O(log n)
红黑树的查找过程本质上是二分查找：
java复制final TreeNode<K,V> find(int h, Object k, Class<?> kc) {
TreeNode<K,V> p = this;
do {
int ph, dir; K pk;
TreeNode<K,V> pl = p.left, pr = p.right, q;
if ((ph = p.hash) > h)
p = pl; // 目标hash小于当前节点，走左子树
else if (ph < h)
p = pr; // 目标hash大于当前节点，走右子树
else if ((pk = p.key) == k || (k != null && k.equals(pk)))
return p; // key相等，找到
else if (pl == null)
p = pr;
else if (pr == null)
p = pl;
else if ((kc != null ||
(kc = comparableClassFor(k)) != null) &&
(dir = compareComparables(kc, k, pk)) != 0)
p = (dir < 0) ? pl : pr; // key实现了Comparable接口，按compareTo比较
else
p = (tieBreakOrder(k, pk) == 0) ? pl : pr; // 兜底比较
} while (p != null);
return null;
}
每一步都排除一半的节点，所以最坏情况下的时间复杂度是O(log n)。注意几个细节：第一，它先比较hash，hash相同才比较key，所以设计良好的hashCode能让查找过程更快地收敛。第二，如果key实现了Comparable接口，红黑树可以利用compareTo来确定方向，避免哈希碰撞时的歧义。第三，tieBreakOrder是个兜底方法，用系统标识比较两个key的类名和身份哈希，保证比较结果不为0，维持红黑树的结构约束。
5.3 树的退化时机：扩容时被拆散的树
前面讲过，扩容时节点会被重新散列。红黑树除了在节点数降到6以下时转回链表，还有一个容易被忽略的退化时机：扩容时被拆分到两个桶的树，如果每个桶里的节点数都不足6，会直接退化成链表。
看resize方法里这段：
java复制if (loHead != null) {
if (lc <= UNTREEIFY_THRESHOLD)
tab[index] = loHead.untreeify(map); // 退化链表
else {
tab[index] = loHead;
if (hiHead != null)
loHead.treeify(tab); // 重新树化
}
}
为什么要重新树化？因为扩容前是一棵完整的树，扩容后节点被拆到两个桶里，可能有一半的节点被移走了。此时每个桶里的链表结构虽然还保留着next关系，但红黑树性质（如黑色节点平衡）可能已经被破坏。如果数量够，需要调用treeify重新构建红黑树。
这个场景很难遇到，但理解它有助于回答“树的退化条件是什么”这个面试题。网上很多答案只说“删除或扩容导致节点数少于6就退化成链表”，其实不完整——扩容时的退化是分桶后各自判断的。
6. resize扩容机制：为什么是2倍扩容，为什么负载因子是0.75
6.1 扩容的触发条件和整体流程
扩容的条件非常简单：put操作新增节点后，如果size > threshold，就调用resize()。这个阈值在非初始化阶段等于capacity * loadFactor。比如默认容量16、负载因子0.75，那么threshold = 12，也就是说HashMap装到12个键值对时，就会触发扩容到32。
resize方法在做的事情分两部分：计算新容量和新阈值，然后迁移所有节点。
第一部分：
java复制if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab; // 不能再扩了，放弃
}
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // 新的阈值是旧的2倍
}
看到没，扩容的核心操作是左移一位，也就是乘以2。不是随便选的倍数，乘以2保证了新容量仍然是2的幂，这样(n - 1) & hash的下标计算才能继续用位运算，而且下面要讲的高低位拆分法才成立。
第二部分是节点迁移，JDK 8的精髓全在这块：
java复制for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null; // 释放旧数组引用，帮助GC
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e; // 单个节点直接算新位置
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap); // 树节点的拆分
else {
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e; // 位置不变的链
} else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e; // 位置偏移oldCap的链
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead; // 原位置
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead; // 新位置 = 原位置 + oldCap
}
}
}
}
6.2 高低位拆分：用一句位运算判断节点去向
这里是最能体现HashMap作者水平的地方。扩容时，桶数组长度从oldCap翻倍到newCap。有一个数学结论：对某个节点，它的hash值在扩容前后对应的桶下标关系是：如果hash & oldCap == 0，下标不变；如果hash & oldCap == 1，新下标 = 旧下标 + oldCap。
证明思路是这样的：下标计算公式是hash & (n - 1)。扩容前n = oldCap，扩容后n = 2 * oldCap。oldCap是2的幂，所以newCap - 1比oldCap - 1多了一个高位1。这个多出来的最高位只有在hash值的对应位为1时才会生效。而这个“对应位”的值恰好等于hash & oldCap。
举个例子：假设oldCap = 16，二进制是00010000。某个key的hash二进制是10110101。扩容前下标 = hash & 15（低4位）= 0101 = 5。扩容后下标 = hash & 31（低5位） = 10101 = 21 = 5 + 16。因为hash的第5位（从低位开始数）是1，也就是hash & 16 == 1，所以下标偏移了oldCap。
如果另一个key的hash是00100101，低5位是00101 = 5，hash & 16 == 0，扩容后下标还是5，没变。
遍历一次链表，根据这个条件拆成两条链，然后直接放到新数组的对应位置。整个过程不需要重新计算hash，不需要取模，每个节点最多移动一次。JDK 7的做法是每个节点都用hash % newCap重新计算位置，性能差了不少。
6.3 负载因子0.75：时间与空间的妥协
为什么默认负载因子是0.75？这个数字不是随便定的。从统计学角度说，当负载因子为0.75时，在理想随机hashCode下，桶内链表长度的泊松分布概率已经极低（前面算过，趋近10的负7次方级别）。如果调大到0.9甚至1.0，空间利用率上去了，但碰撞概率上升，查找性能下降；如果调小到0.5，查找性能更好，但有一半的空间是空的，太浪费。
0.75是一个在时间和空间成本之间取得平衡的经验值。绝大多数业务场景下，这个值不需要动。唯一可能要调整的场景是：你明确知道Map里会装超大容量（比如百万级），又对内存占用极其敏感，可以适当调大负载因子来减少扩容次数——前提是你对性能的退化有心理准备。反过来，如果查找性能是绝对瓶颈，就调小负载因子，用空间换时间。
6.4 初始化容量时最容易踩的坑
很多人在构造HashMap时喜欢这么写：
java复制Map<String, String> map = new HashMap<>(1000);
你以为容量就是1000，实际不是。tableSizeFor会把1000转成1024。但这还不是最坑的，最坑的是：如果明确知道要放1000个元素，负载因子0.75意味着threshold = 1024 * 0.75 = 768，当size达到768时就扩容了，根本到不了1000。
正确的姿势是：
java复制Map<String, String> map = new HashMap<>((int)(1000 / 0.75f) + 1);
或者直接计算成(1000 / 0.75 + 1)向上取2的幂，也就是new HashMap<>(2048)。这个坑在线上很常见，尤其是从数据库查出几万条记录往map里塞的场景，扩容次数多了性能损耗很明显。
Guava的Maps.newHashMapWithExpectedSize(int expectedSize)还写了官方推荐的计算公式：
java复制public static <K, V> HashMap<K, V> newHashMapWithExpectedSize(int expectedSize) {
return new HashMap<K, V>(capacity(expectedSize));
}
static int capacity(int expectedSize) {
if (expectedSize < 3) {
return expectedSize + 1;
}
if (expectedSize < Ints.MAX_POWER_OF_TWO) {
return (int) ((float) expectedSize / 0.75F + 1.0F);
}
return Integer.MAX_VALUE;
}
这个公式在expectedSize小于3时还会额外加1，因为容量太小会导致threshold被tableSizeFor后的结果覆盖，不做特殊处理可能直接初始化就触发扩容。
7. 并发场景下的真实风险：哪些锅该背在HashMap头上
7.1 数据覆盖不是谣言，是真实发生的
HashMap不是线程安全的，这个结论不是空话。两个线程同时执行put，如果它们定位到了同一个桶，并且桶还是空的，那么：
java复制if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
这里有典型的check-then-act竞态。线程A判断桶为空，还没写入时，线程B也判断桶为空，然后A写入node1，B写入node2，同一时刻两个节点写到同一个位置，后写入的覆盖先写入的，另一个节点直接消失。
两个线程同时put两个不同key，映射到同一个桶且桶非空时，也可能发生链表节点互相覆盖，导致其中一个key的value丢了。
还有更隐蔽的：两个线程同时触发扩容，各自创建了新数组，各自迁移节点，最终只有一个新数组会引用，另一个线程迁移的数据全丢。
这些不是理论推导，现实中踩过的人很多。Spring的DefaultSingletonBeanRegistry里就专门用ConcurrentHashMap代替了HashMap来维护单例注册表，官方代码都在防这个。
7.2 快速失败机制：迭代时如何被发现
HashMap的迭代器（包括keySet、values、entrySet的迭代器）都实现了快速失败：迭代过程中如果检测到modCount被修改了，立即抛出ConcurrentModificationException。
java复制final Node<K,V> nextNode() {
Node<K,V>[] t;
Node<K,V> e = next;
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
...
}
所以如果你在遍历HashMap时往里面put了新的key，会立刻抛出这个异常。这是设计上的选择：宁可报错，不让迭代器在错误的数据上静默工作。但注意，modCount != expectedModCount这个判断不是原子操作，多线程环境下依然可能漏过，所以快速失败机制不能作为并发安全的手段，只是提前暴露问题。
7.3 JDK 8有死循环吗？大部分网上说法是编的
网上流传很广的一个说法：HashMap并发扩容时，因为JDK 7的头插法倒置链表，可能形成环形链表，get时死循环导致CPU打满。JDK 8改成尾插法后这个问题解决了。
这句话前半段是对的，后半段要谨慎。JDK 8的尾插法确实消除了由于链表倒置引起的环形链表问题，但并发环境下两个线程同时执行resize，依然可能出现节点迁移互相覆盖、链表中某个节点的next被错误设置的情况，极端情况下依然可能形成环。只能说概率大幅降低，不能说彻底解决。
我见过线上一个事故，JDK 8环境下并发put同一个key到同一个HashMap，结果get返回了null，而且那个key明明已经put成功了。排查半天，是因为并发扩容时两个线程各自拆分了链表，其中一个桶里的节点最终没有被正确关联到新数组上，数据丢失了。
所以我的建议很直接：任何涉及多线程读写的Map场景，一律使用ConcurrentHashMap。读多写少的场景用Collections.synchronizedMap都能忍，就是别裸用HashMap。这个建议我已经重复了很多年，也打算继续重复下去。
8. 实战经验与调优：从源码走向生产环境
8.1 重写equals和hashCode时的黄金法则
HashMap的查找完全依赖hashCode和equals这两个方法。Java官方约定：equals相等的两个对象，hashCode必须相等；hashCode相等的两个对象，equals不一定相等。违反这个约定，HashMap直接失效。
举个例子，你定义了一个User类：
java复制class User {
private String name;
private int age;
// 只重写了equals，没有重写hashCode
}
如果你只重写了equals而没重写hashCode，那equals相等的两个User对象，hashCode可能不同，HashMap就会把它们当成两个key存到不同桶里。你put的时候用的是userA，get的时候拿userB去查，永远查不到。
还有一个更隐蔽的坑：用可变对象作为key。比如key是一个ArrayList，put进HashMap之后再往ArrayList里add元素，导致它的hashCode变了。下次get用同一个对象去查，但它的hash已经变了，定位到的桶已经不同，数据就找不到了。
所以实际开发中我的建议是：
- 优先用String、Integer这类不可变类型作为key；
- 自定义类作为key时，要么保证字段不可变，要么在放入后再也不修改它；
- equals和hashCode必须同时重写，用IDE自动生成即可，不要手写。
8.2 一个真实的容量预估案例
我这里有个实际的业务场景。做订单导出功能，需要把10万条订单数据按订单号分组：
java复制Map<String, List<Order>> orderGroupMap = new HashMap<>();
for (Order order : orders) {
orderGroupMap.computeIfAbsent(order.getOrderNo(), k -> new ArrayList<>()).add(order);
}
如果直接这么写，HashMap的初始容量是16，但实际要放10万个key，中间会经历多次扩容，每次扩容要重新散列所有节点，这段时间GC压力特别大，接口RT直接飙升。改成：
java复制int expectedSize = 100000;
Map<String, List<Order>> orderGroupMap = new HashMap<>((int)(expectedSize / 0.75f) + 1);
初始容量直接给到(int)(100000 / 0.75f) + 1 = 133334，tableSizeFor取整成262144。这样一次性分配到位，全程无扩容，内存占用多一些，但处理速度显著提升。在数据量明确且大的场景里，这个优化性价比极高。
8.3 JDK 11和17里的HashMap变化
JDK 8和后续版本的HashMap差别不大，但有几个细节值得提。
JDK 9引入了Map.of()系列静态工厂，返回的是不可变Map，底层不是HashMap，而是一种更紧凑的存储方式，适合小规模常量Map。JDK 10在java.util.HashMap里没动核心逻辑，但ConcurrentHashMap做了不少优化。JDK 17的HashMap核心逻辑和JDK 8一致，只是modCount和threshold等字段增加了@SuppressWarnings注解和代码风格调整，树化和扩容逻辑完全一样。
我目前线上主要跑JDK 11和17，HashMap的行为和JDK 8没有任何差异。
8.4 HashMap排序的两种常见做法
很多人问HashMap怎么排序。HashMap本身就是无序的，排序需要把entrySet取出来放到一个有序结构里。两种常见做法：
java复制// 方法一：转成List再排序
map.entrySet().stream()
.sorted(Map.Entry.comparingByValue())
.collect(Collectors.toMap(
Map.Entry::getKey,
Map.Entry::getValue,
(e1, e2) -> e1,
LinkedHashMap::new
));
// 方法二：直接用TreeMap（字典序排列）
TreeMap<String, Integer> sortedMap = new TreeMap<>(map);
方法一灵活，可以按照任意规则排序；方法二快速，适合按key的自然顺序排列。注意用Collectors.toMap时要指定LinkedHashMap作为结果收集器，否则默认返回的还是HashMap，排序结果全丢。这个坑我在code review里见过不少次。
8.5 从源码阅读中学到的编程思想
读HashMap源码最大的收获，不是背下来那些阈值参数，而是学习JDK作者在权衡取舍时的思考方式。树化阈值取8是概率统计的结果，负载因子0.75是时间和空间的平衡点，扩容采用高低位拆分是为了避免重算hash，懒加载初始化是为了节省内存。每个设计决策背后都有一组清晰的约束条件和优化目标。
理解了这种思考方式，你再看ConcurrentHashMap的源码，会发现它的分段锁、CAS操作、size计算方式，都是在同一个权衡框架下的不同选择。看Tomcat的内存缓存、Guava的本地缓存，也会有这种“原来设计者是这么权衡的”的顿悟感。
我自己的体会是，源码读完后，不必追求每一行都记住，但要把那些关键的权衡记在心里。下次设计自己的组件时，遇到类似场景，就知道该从哪些维度去分析问题，该在哪些约束下做取舍。
这个话题我能聊的还有很多，比如红黑树的左旋右旋过程、TreeNode的split方法细节、迭代器具体的fail-fast实现路径，但这些更适合在有具体问题的时候再展开。如果你读源码时碰到看不懂的地方，欢迎私信或者评论里聊，我尽量回复。