HashMap是如何进行扩容的？

HashMap 不扩容的致命隐患

1. 哈希冲突指数级攀升，性能断崖式下跌

随着 HashMap 不断插入新元素，在不扩容的情况下，由于桶的数量固定，新元素会大量聚集在同一或相邻桶中，导致哈希冲突概率呈指数级上升。
当哈希冲突严重时，即使链表转换为红黑树结构，查询效率也会从理想的 O(1) 骤降至 O(log n) 。
例如，初始容量为 16 的 HashMap ，在元素数量超过 12（负载因子 0.75）且未扩容时，新增元素产生哈希冲突的概率大幅增加，直接影响数据存取效率。

2. 极端场景下性能彻底劣化

在极端情况下，所有元素可能会落入同一个桶中，此时链表查询效率将退化至 O(n) 。
虽然链表长度达到阈值后会转换为红黑树，查询效率提升至 O(log n) ，但相较于扩容分散元素、维持哈希表的均匀分布，这种方式无疑是 “治标不治本” 。
以存储 1000 个元素为例，若全部集中在一个桶中，即便转为红黑树，查询效率也远不及通过扩容将元素均匀分布在多个桶的情况。

由此可见，扩容机制是 HashMap 维持高性能的核心保障。通过动态调整容量，及时分散元素，能够有效避免哈希冲突的恶化，确保数据存取始终保持高效 。

扩容的触发时机是什么时候？

1. HashMap内部有一个负载因子，初始化时如果不指定，则默认为0.75f。当HashMap的元素超过 数组长度【或者说桶的数量】×负载因子的时候，就会触发扩容。

2. 还有另外一个场景：树化。
   在 HashMap 中，​链表转换为红黑树（树化）时不会直接触发扩容，但树化前会有一个关键的判断条件：如果当前哈希表的数组长度（桶数量）未达到 ​最小树化容量阈值（MIN_TREEIFY_CAPACITY=64）​，HashMap 会优先选择扩容而不是树化。

JDK8源码中具体的判断如下：

// HashMap.putVal 方法片段
for (int binCount = 0; ; ++binCount) {
    if ((e = p.next) == null) {
        p.next = newNode(hash, key, value, null);
        // 链表长度 >= 7（从0开始计数）时尝试树化
        if (binCount >= TREEIFY_THRESHOLD - 1) // TREEIFY_THRESHOLD=8
            treeifyBin(tab, hash); // 调用 treeifyBin
        break;
    }
    // ...省略冲突检查逻辑
}

//树化方法
final void treeifyBin(Node<K,V>[] tab, int hash) {
    int n, index; Node<K,V> e;
    // 关键判断：若数组长度 < 64，优先扩容而不是树化
    if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
        resize(); // 触发扩容
    else {
        // 数组长度 ≥ 64 时，执行树化逻辑
        // ...
    }
}

扩容和树化关系：

那么这里提出一个问题：为什么优先扩容而不是直接树化？

先想想，如果直接树化会怎么样？首先原本的哈希冲突概率肯定是不会减少的，因为桶的数量不变，元素的数量越量越多，树化的结果只是提高了桶里链表的查询效率。
这里有个前提是，数组长度小于64的时候，才会进行优先扩容。

结合以上这两点分析，设计者认为，在数组长度小于64的时候，扩容带来的收益是高于树化的。

OK,这是我目前能够想到的，然后通过AI查询，它给我了四个说法：

1. 扩容的分散效果
   当数组容量较小时，哈希冲突的概率更高，但扩容可以重新分配元素到更大的数组中，减少单个桶的链表长度。例如，容量从16扩容到32时，原链表可能被拆分为两个较短的链表（如长度4），避免后续操作的低效。此时扩容的收益可能超过树化。
   ​2. 树化的开销较高
   红黑树在节点较少时（如长度为8的链表转换成的树），插入、删除和旋转操作的开销可能大于链表操作。而扩容后链表变短，链表的遍历成本可能反而低于树的维护成本。
   ​> 3. 空间效率
   树节点（TreeNode）比普通链表节点（Node）占用更多内存（需存储左右子节点、颜色等）。小容量时过早树化可能导致内存浪费，而扩容的额外空间增长相对可控。
   ​> 4. 设计优化与阈值设定
   HashMap定义了常量MIN_TREEIFY_CAPACITY=64，经过测试发现，**当容量达到64时，哈希表已具备一定规模，树化的性能收益超过扩容成本。**而小于64时，扩容更优

关于扩容的收益是不是真的超过树化，这个已经经过设计者验证了,不需要经过我们自己再去验证了，只需要believe。

Java集合框架的设计者（如Doug Lea、Joshua Bloch等）在实现HashMap时，会通过微基准测试​（Microbenchmarks）和实际应用场景模拟验证扩容策略。

那为什么数组超过64了之后，就直接树化了？感觉直接扩容也可以？

这里经过AI问答，有个答案我是比较满意的：

阈值64的合理性:
​经验与测试的结论：通过大量测试，设计者发现当数组容量≥64时，哈希表已具备足够的分散能力。若此时某个桶的链表长度仍达到8，说明哈希冲突已无法通过扩容解决，必须树化。
​空间与时间的平衡：
​节点较少时（链表长度<8）​：链表的遍历成本低，且树节点（TreeNode）的内存开销（约普通节点的2倍）不划算。
​节点较多时（链表长度≥8）​：树化的性能收益超过内存开销，而容量≥64时，哈希表已足够大，树化后剩余桶可以容纳后续元素。

简单来说就是，超过64容量的哈希表，它已经具备足够的分散能力，如果依然有链表到达了8，那么可能它的哈希冲突只集中在少量桶中，此时树化的收益是大于扩容的。

扩容的详细过程

OK，搞定了为什么需要扩容之后，再来看看它是怎么扩容的？
先来想想，如果让我来设计扩容，大概会怎么设计？

1. 首先创建一个新的数组
2. 然后将旧数组的元素复制进去
3. 将HashMap的底层数组改为引用新数组

HashMap的核心流程也没多少区别，但是细节会比较有讲究：
第一，创建新数组，打算新数组有多长？
这里HashMap会把新数组的长度定位为旧数组的2倍【通过位运算,newCap = oldCap <<1】，HashMap初始化数组时候长度也是2的幂次方，在HashMap初始化时会调用以下方法：

static final int tableSizeFor(int cap) {
        int n = cap - 1;
        //这里的意思是右移一位，然后与原值按位或操作，例如 7 = 0111，n>>>1后变成0011，n| = n>>>1 就变成0011|0111 = 0111
        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;
    }

只需要知道，这段方法的目的，是为了保证HashMap里数组的长度是2的 幂次方。

为什么要这么做？

假设HashMap的容量不是2的幂次方，针对添加元素的场景，添加元素时，首先得计算它的Hash值，然后再与数组的长度进行与运算找到它的桶。如果数组的长度是2的幂次方，那么数组长度的二进制就都是1，进行与运算的结果就会由元素的Hash值完全决定,而且这个hash值是经过扰动函数处理的，目的是减少哈希冲突概率。如果不是2的幂次方，那么下标就会由数组长度和Hash值共同决定，那么扰动函数的处理意义就不大了。

为什么不是模运算？

因为HashMap使用 hash &(n-1) 的性能比 hash%n 要快，而且在数组长度为2的幂次方的情况下，hash &(n-1) 等价于hash%n 。

创建完新数组之后，怎么把旧数组的元素转移到新数组里面？

这里不是直接的把原数组copy一份到新数组里面，因为扩容的目的，是降低数据的哈希冲突概率，让数组上的链表不那么长，提高查询效率。所以在转移过程中，会对key重新进行哈希，得到新的下标。

final Node<K,V>[] resize() {
        Node<K,V>[] oldTab = table;
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        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; // double threshold
        }
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               // zero initial threshold signifies using defaults
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        if (newThr == 0) {
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        @SuppressWarnings({"rawtypes","unchecked"})
        Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
            for (int j = 0; j < oldCap; ++j) {
                Node<K,V> e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    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 { // preserve order
                        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;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

总结

通过以上对 HashMap 扩容机制的详细分析，我们了解了扩容的触发时机、新数组长度的确定、元素转移的过程以及性能分析。HashMap 的扩容机制是为了保证其性能优势，在元素数量增加时，通过扩容和树化等操作，降低哈希冲突概率，提高查询效率。