1. 从一次线上故障说起为什么需要关心HashMap扩容那天晚上系统监控突然报警一个核心接口的响应时间从几十毫秒飙升到了几秒。紧急排查日志发现并没有明显的慢SQL也没有外部依赖超时。最终通过分析线程堆栈和内存快照我们把问题定位到了一个高频使用的、用于缓存用户临时数据的HashMap上。这个Map的初始容量设置得很小但在业务高峰期数据量激增触发了频繁的扩容Rehashing操作。每次扩容都需要重建哈希表这是一个O(n)时间复杂度的操作并且会阻塞所有向该Map进行put操作的线程在高并发场景下瞬间就形成了性能瓶颈。这个经历让我意识到很多开发者包括曾经的我对HashMap的认知可能停留在“会用”的层面知道它快知道它基于哈希表但对于其内部如何动态调整以适应数据量变化——也就是扩容机制——往往一知半解。而这恰恰是影响其性能表现尤其是在数据量不可预知或并发环境下最关键的部分之一。理解扩容不仅是面试时需要背诵的八股文更是写出高性能、高稳定性代码的必备知识。今天我们就抛开那些笼统的概念深入HashMap以主流的JDK 8为例的源码层面把扩容机制掰开揉碎了讲清楚。2. HashMap的底层结构数组、链表与红黑树在深入扩容之前我们必须先清晰理解HashMap的底层数据结构因为扩容操作直接作用于这个结构之上。很多人背过“数组链表”但在JDK 8之后这已经不够准确了。HashMap内部维护了一个NodeK,V[] table数组我们称之为“桶数组”bucket array。每个数组元素称为一个“桶”bucket。当你调用map.put(key, value)时HashMap会做以下几件事计算哈希值首先根据key的hashCode()方法计算出一个哈希值int类型。扰动函数处理这个哈希值并不会直接用作数组下标。HashMap使用了一个称为“扰动函数”的操作(h key.hashCode()) ^ (h 16)。这个操作的目的是将哈希值的高位特征也参与到后续的运算中目的是为了减少后续步骤发生哈希碰撞的概率。试想如果两个对象的hashCode()只在低位有差异而数组长度不大那么它们很可能被映射到同一个桶里。将高16位与低16位进行异或相当于混合了原始哈希码的高位和低位以此来增加低位的随机性。计算桶索引通过(n - 1) hash这个操作确定键值对应该放入哪个桶即数组的哪个下标。这里n是当前table数组的长度。这个操作的原理是取模运算的优化版本。因为HashMap强制要求数组长度n永远是2的幂如16, 32, 64那么n-1的二进制表示就是一串连续的1例如15的二进制是1111。(n-1) hash这个位与操作实际上就是取哈希值hash的低log2(n)位其结果等价于hash % n但位运算的效率远高于取模运算。当两个不同的key经过上述计算后落入了同一个桶即发生了哈希碰撞HashMap就需要解决这个冲突。在JDK 8之前它采用“拉链法”即在数组的每个元素上挂一个单向链表。新来的节点插入到链表的头部头插法。JDK 8的重要优化链表树化在JDK 8中当同一个桶中的链表长度超过一定阈值默认为8并且当前桶数组的长度达到一定规模默认为64时HashMap会将这个链表转换为红黑树TreeNode。红黑树是一种自平衡的二叉查找树它将在此桶上进行查找、插入操作的时间复杂度从链表的O(n)降低到O(log n)。这是一个非常重要的优化旨在防止在极端情况下例如所有key的哈希值都冲突到同一个桶HashMap的性能退化为链表。同样在扩容或删除元素后当树中的节点数减少到较小值默认为6时红黑树会退化为链表以节省空间。所以准确地说JDK 8的HashMap底层是“数组链表红黑树”的复合结构。扩容操作需要同时处理这三种形态的数据。3. 触发扩容的核心条件与关键参数HashMap不会在每次插入新元素时都检查是否需要扩容那太浪费性能。它通过几个核心参数来智能地决定何时扩容。capacity容量指底层table数组的长度。它必须是2的幂。默认初始容量是16(1 4)。loadFactor负载因子这是一个浮点数默认值为0.75f。它决定了HashMap在容量自动增加之前允许其达到多满的一种尺度。threshold扩容阈值这是一个整型变量计算公式为threshold capacity * loadFactor。它是触发扩容的“警戒线”。扩容的核心触发条件只有一个当HashMap中键值对的数量size超过当前扩容阈值threshold时就会触发扩容resize()。举个例子默认情况下capacity16,loadFactor0.75那么threshold12。当你向一个空的HashMap中成功插入第13个键值对size从12变为13时size (13) threshold (12)条件成立扩容就会被触发。这里有一个非常重要的细节size是HashMap中实际存在的键值对数量而threshold是基于当前数组容量计算出来的。负载因子0.75是时间和空间成本的一个折中选择。如果负载因子过高例如1.0虽然空间利用率高了但哈希碰撞的概率会急剧增加导致链表变长或树化查找性能下降。如果负载因子过低例如0.5虽然碰撞减少查找很快但会频繁触发扩容消耗更多内存和重建哈希表的计算资源。0.75是一个经过大量实践检验的较优值。注意除了上述主要条件在链表树化时还有一个隐含条件。当某个桶的链表长度达到8但当前table数组长度capacity小于MIN_TREEIFY_CAPACITY默认64时HashMap不会立即将该链表树化而是会选择先进行一次扩容。因为扩容后原来在同一个桶里的节点可能会被分散到新的桶中链表长度自然缩短可能就不再满足树化条件了。这是一种“尝试通过扩容来解决过度冲突”的优化策略。4. 扩容的详细过程一次完整的Rehash拆解当触发扩容后HashMap会调用resize()方法。这是整个类中最核心也最复杂的方法之一。我们可以将其过程分解为以下几个步骤4.1 第一步确定新容量与新阈值首先HashMap需要确定新的桶数组应该有多大。如果旧数组oldCap 0说明这不是初始化后的第一次扩容。那么新容量newCap通常直接翻倍oldCap 1直到达到最大容量MAXIMUM_CAPACITY1 30。新阈值newThr也相应地翻倍oldThr 1。如果旧数组是初始化时的空数组通过new HashMap()创建但未指定参数那么如果创建时指定了初始容量initialCapacity则threshold在初始化时被暂时存储为符合2的幂的容量值。此时新容量newCap就等于这个threshold新阈值newThr newCap * loadFactor。如果使用无参构造函数则使用默认值newCap 16,newThr 12。为什么容量必须是2的幂这关乎到我们之前提到的(n-1) hash这个计算索引的操作。当n是2的幂时n-1的二进制形式是000...0111...1一串连续的1。hash (n-1)的结果相当于均匀地取了hash值的低几位。这有两个巨大好处运算高效位与()操作是CPU原生支持的超快操作比取模(%)快得多。分布均匀只要hash值本身分布均匀与(n-1)进行位与后结果在[0, n-1]区间内也是均匀分布的能有效利用所有桶。 如果n不是2的幂n-1的二进制中就会有0位。任何hash值与0位相与结果都是0这意味着某些桶的索引永远不可能被计算出来导致数组空间浪费并且哈希碰撞会更集中到某些特定的桶上。4.2 第二步创建新数组并迁移数据Rehashing创建好新的、容量翻倍的NodeK,V[] newTab后最核心、最耗时的步骤开始了将旧数组oldTab中的所有节点Node/TreeNode迁移到新数组中。这个过程称为“重哈希”Rehashing。迁移不是简单地将旧数组里的链表或树原封不动地拷贝过去。因为数组长度n变了计算桶索引的公式index (n-1) hash中的n也变了。所以每个节点都必须根据其key的哈希值和新数组长度重新计算它在新数组中的位置。在JDK 8中这个迁移过程有一个非常巧妙的优化。由于扩容是翻倍newCap oldCap 1新数组长度newCap是旧数组长度oldCap的2倍。那么一个节点在新数组中的位置要么和原位置相同要么是原位置 oldCap。这是如何推导出来的假设旧容量oldCap 16二进制为10000oldCap-1 15二进制为01111。 一个节点的哈希值hash与01111做位与得到了它在旧数组中的索引我们记为oldIndex。这个操作本质是取了hash的低4位。 扩容后新容量newCap 32二进制为100000newCap-1 31二进制为11111。 现在hash需要与11111做位与这本质是取hash的低5位。那么节点新位置newIndex就取决于hash的第5位从低到高0开始计数是0还是1。如果第5位是0那么newIndex的低5位就是0xxxx后4位是oldIndex即newIndex oldIndex。如果第5位是1那么newIndex的低5位就是1xxxx这正好等于oldIndex 10000二进制也就是oldIndex oldCap。因此在迁移时HashMap无需重新计算hash值hash是存储在Node节点中的final字段只需要判断(hash oldCap) 0这个条件若为true则节点新位置为oldIndex。若为false则节点新位置为oldIndex oldCap。4.3 第三步处理链表与树的拆分基于上述优化迁移时HashMap会遍历旧数组的每个桶如果桶为空跳过。如果桶里只有一个节点没有发生碰撞直接根据(hash oldCap) 0计算新位置放入新数组。如果桶里是一个链表HashMap会创建两个低位链表loHead/loTail和两个高位链表hiHead/hiTail。然后遍历原链表对每个节点判断(hash oldCap) 0若为真将该节点挂到低位链表。若为假将该节点挂到高位链表。 遍历结束后将低位链表头节点loHead放到新数组的oldIndex位置将高位链表头节点hiHead放到新数组的oldIndex oldCap位置。这里注意JDK 8采用了尾插法来构建这两个新链表而JDK 7及之前是头插法。尾插法避免了在并发环境下可能产生的环形链表问题虽然HashMap本身非线程安全但这是一个代码改进。如果桶里是一棵红黑树处理逻辑与链表类似但更复杂。TreeNode也维护了双向链表结构。HashMap会同样地将树节点拆分为低位树节点链表和高位树节点链表。拆分后会检查每个链表的长度如果长度小于等于UNTREEIFY_THRESHOLD默认为6则调用untreeify方法将TreeNode链表转换为普通的Node链表。如果长度大于6则调用treeify方法尝试将新的链表重新树化。注意重新树化还需要满足新数组长度newCap 64的条件。完成所有桶的遍历和迁移后将HashMap的table引用指向新的数组newTab并更新threshold为newThr。至此一次完整的扩容结束。5. 多线程下的扩容隐患死链与数据丢失HashMap的源码注释明确写道“此实现不同步。如果多个线程同时访问一个哈希映射并且至少有一个线程从结构上修改了该映射则它必须保持外部同步。” 结构修改是指任何添加或删除一个或多个映射关系的操作仅更改与实例已包含的键关联的值不是结构修改。在并发环境下进行扩容主要会引发两类问题死循环JDK 7及之前的典型问题在JDK 7中迁移链表时采用头插法。假设有两个线程A和B同时触发扩容都开始执行迁移。在迁移某个链表时由于CPU时间片切换可能导致线程A刚修改了某个节点的next指针后挂起线程B完成了完整的迁移并形成了新的链表。当线程A恢复执行时其持有的旧链表节点引用可能已经失效在后续的指针操作中极有可能形成环形链表。此后任何线程尝试对这个桶进行遍历如get操作就会陷入死循环CPU占用率飙升。数据丢失这是更普遍的问题。由于size的增加、table引用的切换、链表指针的修改都不是原子操作并发操作下可能导致覆盖写入两个线程同时put都判断不需要扩容读取到旧的threshold然后计算到同一个桶位置先后写入节点后写入的会覆盖先写入的。扩容丢失线程A触发扩容创建了新数组正在迁移数据。此时线程B执行put它可能看到的是尚未迁移完成的旧数组或已经切换的新数组导致其插入的节点在扩容完成后丢失。size不准确size的自增操作size非原子并发下会导致最终size小于实际插入的数量。重要提示JDK 8通过将头插法改为尾插法修复了在扩容时可能形成的死循环问题。但这绝不意味着HashMap可以在多线程下安全使用数据丢失、size不准等问题依然存在。在并发场景下必须使用ConcurrentHashMap或者通过Collections.synchronizedMap对HashMap进行包装或者在使用处进行外部加锁。6. 初始化与扩容的性能优化实践理解了扩容机制我们就能在实战中做出优化避免文章开头提到的性能问题。1. 预估容量避免频繁扩容这是最重要的优化手段。如果你能大致预估HashMap最终会存放多少键值对size那么应该在创建时就指定一个合适的初始容量。// 假设预计要存储100个元素 int expectedSize 100; // 计算初始容量 expectedSize / loadFactor 1 int initialCapacity (int) (expectedSize / 0.75f) 1; // 创建HashMap MapString, Object map new HashMap(initialCapacity);通过(int) (expectedSize / 0.75f) 1计算初始容量可以保证HashMap在存入expectedSize个元素的过程中一次扩容都不会发生。因为threshold capacity * 0.75只要expectedSize threshold就不会触发扩容。加一是为了向上取整提供一点余量。2. 理解负载因子的权衡除非有非常特殊且确切的理由否则不要轻易修改默认的负载因子0.75。降低负载因子如设为0.5会让哈希表更“空旷”减少碰撞提升查找速度但会以更早、更频繁的扩容和更多的内存消耗为代价。增加负载因子如设为0.9可以提高内存利用率减少扩容次数但会显著增加哈希碰撞可能导致大量链表甚至树化在查找时拉低性能。0.75是官方经过大量测试得出的经验值在绝大多数场景下都是最佳选择。3. 键对象的hashCode()与equals()HashMap的性能极度依赖于键的hashCode()方法。一个好的hashCode()应该一致性在对象状态未改变时多次调用返回相同值。高效性计算不能太复杂。离散性对于不同的对象应尽可能产生不同的哈希值均匀分布。 糟糕的hashCode()例如总是返回1会让所有键都碰撞到同一个桶使HashMap退化为链表或一棵大而深的树性能急剧下降。同时equals()方法也必须被正确重写以确保哈希碰撞时能正确找到对应的键。4. 迭代过程中的结构性修改使用迭代器如entrySet().iterator()遍历HashMap时如果直接调用Map的remove()方法删除元素会导致ConcurrentModificationException。正确做法是使用迭代器自身的remove()方法。这是因为HashMap维护了一个modCount修改次数变量迭代器在初始化时会记录当前的modCount在每次迭代操作如next()时会检查modCount是否被改变如果被改变说明有其他操作结构性修改了Map就抛出异常。这是一种“快速失败”fail-fast机制旨在帮助开发者尽早发现并发修改的bug。HashMap的扩容机制是其高效性的动态保障也是其并发脆弱性的根源。从数组长度的2的幂约束到负载因子的精妙平衡再到Rehash时位运算的巧妙优化每一步都体现了设计者对性能的极致追求。作为开发者我们不仅要会用更要理解其内在原理。这样在遇到性能瓶颈时你才能像侦探一样从现象响应时间变慢快速定位到可能的原因频繁扩容并给出有效的解决方案合理初始化容量。下次当你准备new HashMap()时不妨先花一秒思考一下“我大概要放多少数据” 这个简单的习惯或许就能避免一次深夜的线上告警。