怎么理解 HashMap 的底层哈希表实现

怎么理解 HashMap 的底层哈希表实现

谈到HashMap，很多人知道它快，但快从何来？其底层实现，本质上是用“数组 + 链表/红黑树”这套组合拳，模拟了一张逻辑上的散列表。核心目标非常明确：把任意一个键（Key）快速、准确地映射到一个固定的内存位置，从而实现平均接近 O(1) 的存取效率。这听起来简单，背后的设计却充满了权衡与巧思。

数组是主干，“桶”决定落点

一切的基础是一个名为 Node[] table 的数组。你可以把它想象成一排排的“桶（bucket）”。数据并非按顺序存放，而是由键的哈希值来决定它的“家”在哪。举个例子，键 "user123" 经过自身的 hashCode() 方法计算，再经过HashMap内部的扰动函数处理，得到一个最终的哈希值，假设是 1987。接着，用这个值对当前数组长度取模（比如 1987 % 16 = 3），结果 3 就是它的归宿——索引为3的那个桶。这个过程，就是所谓的“哈希函数定位”，是高效访问的起点。

冲突不可避免，链表和红黑树来兜底

理想很丰满，现实却难免碰撞。不同的键完全有可能计算出相同的数组下标，这就是“哈希冲突”。比如 "abc" 和 "def" 都落到了索引5的桶里。怎么办？覆盖显然不行。于是，HashMap采用了链式结构：后来的节点就接在已有节点之后，形成一个链表。

• 在插入方式上，JDK 7采用的是头插法，而JDK 8改为了尾插法。这一改动主要是为了解决并发扩容时可能引发的环形链表问题，提升了稳定性。
• 那么，链表会不会太长导致查找变慢？当然会。因此，当链表长度增长到 ≥ 8 并且 此时数组的总长度也 ≥ 64 时，链表会自动升级为红黑树。这个数据结构能将查找性能从链表的 O(n) 提升到 O(log n)。
• 反过来，如果因为删除操作导致树中的节点数减少到 ≤ 6，红黑树又会退化成链表。这避免了在数据量较小时，维护树结构带来的额外开销。

看，这里全是平衡的艺术：在空间、时间和实现复杂度之间寻找最佳实践。

键的比较必须成对重写：hashCode() + equals()

HashMap如何判断两个键是“相同”还是“不同”？这个过程是两步走的严谨校验：

• 首先比较 hashCode()：如果两个键的哈希值不同，那么它们肯定不是同一个键，可以直接放入新的位置或链表末尾。
• 如果哈希值相等（发生了哈希碰撞），事情就没那么简单了，这时需要请出 equals() 方法进行内容的深度比较：返回 true，则视为重复键，新值会覆盖旧值；返回 false，则视为不同的键，会在链表或树中新增一个节点。

这就引出一个至关重要的实践规则：当你打算用自定义的类对象作为HashMap的键时，必须同时、一致地重写 hashCode() 和 equals() 方法。否则，即使两个对象的内容完全一致，也会因为默认的Object类方法（比较内存地址）而被判定为不同的键，导致数据重复存储，这显然不是我们想要的结果。

扩容不是小事，影响性能的关键环节

HashMap不是一成不变的，它需要成长。初始容量默认是16，加载因子默认是0.75。这意味着，当桶数组中的元素数量达到 容量 × 加载因子（即 16 * 0.75 = 12）时，扩容机制就会触发。

• 扩容时，会创建一个容量为原来两倍的新数组（例如从16扩大到32）。
• 接下来是一个相对耗时的操作：遍历旧数组中所有的节点，为每个节点基于新数组长度重新计算哈希和下标，然后将它们迁移到新数组对应的新“桶”中。
• 这个过程对于链表和红黑树节点同样适用，红黑树在迁移过程中还会进行必要的平衡调整。

正因为扩容涉及大量的数据重新分配，对性能有直接影响，所以如果能在初始化时就预知大致的数据量规模，建议直接指定一个合理的初始容量（例如 new HashMap(1024)），这样可以有效减少后续扩容的次数，提升整体性能。