原文来自于：https://zha-ge.cn/java/54

Java HashMap 扩容机制详解：触发条件与实现原理

有时候，写 Java 写着写着，HashMap 就开始耍小脾气。要么莫名其妙慢下来，要么空间蹭蹭见底，最后一看，原来是扩容背锅。今天就来聊聊我和 HashMap 扩容那些见不得人的内幕，顺便带一点代码小料。

那次 HashMap 把我搞懵了

先交代下场景：那会儿我在做个高并发日志聚合服务，业务量增长飞快。内存明明还挺大，CPU 占用突然就暴涨。下意识觉得啥锁卡死了？JDWP 监控半天，发现某段业务竟然全卡在 HashMap 里！我的第一反应：不会是扩容在搞事吧？

于是就打开源码，边啃边吐槽。

扩容的小九九

HashMap 的扩容，其实是“一拍脑门”规律。

• 容量（capacity）：桶的个数
• 负载因子（loadFactor）：默认 0.75
• 扩容阈值（threshold）：capacity × loadFactor

只要 size 超过 threshold，HashMap 就要大搬家！每次容量翻倍，然后 Rehash，老键全都要洗个三温暖。堪比程序员大重构。

小代码一把梭

来抄下源码核心片段，约 10 行出头：

if (size >= threshold) {
    // 升级容量
    resize();
}

void resize() {
    // 容量变两倍
    Node<K,V>[] newTab = new Node[oldCap << 1];
    // 重哈希老数据
    for (Node<K,V> e : oldTab) {
        // ...把节点丢进新桶
    }
}

有没有发现？扩容一到位，CPU 很快就不淡定。插入不是“补一块砖”，而是“全楼拆迁”。

踩坑瞬间

有些朋友老喜欢这么用：

Map<String, String> map = new HashMap<>();
for (...) {
    map.put(k, v);  // 插满自动扩容！
}

• 没指定初始容量，默认开 16 个桶。
• 业务数据一多，每塞满 12 个元素就 realloc 一次。
• 瞬间三连扩容 + Rehash，内存抖三抖。

最骚的是，如果你用大小刚好 2 的幂，感觉没问题。可有业务激增，过 thousand 条，扩容抖得比我写的周报还频繁！那 CPU 峰值，真让人头皮发麻。

手动避坑指南

后来我乖多了。新建 HashMap，直接：

int expectSize = 5000;
int initCapacity = (int) (expectSize / 0.75f) + 1; // 6670
Map<String, String> map = new HashMap<>(initCapacity);

技巧 combo：

• 预估最大元素，按 0.75 加一刀。
• 不要等着扩容惩罚 CPU。
• 生产居然稳住了，再也没见到爆表。

经验启示

• HashMap 扩容很 “懒”，等到阈值才挪窝，一挪就全家搬家超耗能。
• 预估好初始容量，能省老鼻子资源。要伸手就伸大一点！
• 涉及大批量、高并发插入，一定要提前分配，别让扩容成“定时炸弹”。
• 插入超多数据时，HashMap 真心不快，考虑别的 Map 实现（比如 ConcurrentHashMap）。

哦对，这次学乖了。以后看到 HashMap，先估一把容量，不做小气鬼，代码和 CPU 都能松口气。反正内存又不是自己掏钱买的（老板：你说啥？）。
OK，今天 HashMap 的“扩容风波”就聊到这，溜了溜了——下次再踩坑记得拉我一把。