Java HashMap 扩容为什么会拖慢批量导入：容量估算与并发写入边界

批量导入 80 万条数据时，日志里没有报错，耗时却每隔一段时间突然抬头。把耗时拆开后，慢点集中在把记录放进临时 HashMap 的阶段：不是每次写入都慢，而是容量接近阈值时出现一段集中搬迁。

批量导入的慢点为什么总在某几个区间出现

先看一个很常见的业务场景：导入程序读取 CSV 之后，以业务编号为 key，把清洗规范化后的记录放进内存索引：

Map rows = new HashMap();
for (ImportRow row : source) {
    rows.put(row.businessNo(), row);
}

如果不手动指定初始容量，构造出来的 HashMap 会从很小的桶数组开始运行。元素总数量超过当前阈值后，HashMap 会申请一块更大的数组，再把已经存入的所有节点重新排布到新的桶位里。单次扩容单独看是摊销性能可接受的操作，但放在大批量导入任务里，这个操作会集中占用 CPU 和内存带宽，刚好就表现为一段毫无征兆的写入停顿。

先把容量、阈值和真实数据量对上

HashMap 的阈值大致等于当前容量乘以负载因子。默认负载因子为 0.75，所以容量为 16 时，阈值通常是 12；容量扩大到 32 后，阈值随之变成 24。这里的“容量”指桶数组长度，不是可以直接放入的键值对数量。

导入 100000 条记录且希望中途不触发扩容，可以先按负载因子倒推需要的容量，再向上取最接近的 2 的幂。JDK 自带的构造器内部就会自动把传入的请求容量调整到符合规则的桶数组大小：

int expected = 100_000;
int initialCapacity = (int) (expected / 0.75f) + 1;
Map rows = new HashMap(initialCapacity);

如果数据量只是预估上限，不是每次导入都能稳定达到的数值，没必要把容量一次性设置得特别大。过大的桶数组会占用大量空槽位，反而会让短生命周期的导入任务内存峰值变得更高。容量估算的目标是减少已知范围内的扩容次数，而不是追求完全不会增长的极端值。

用一个检查点验证估算是否有效

排查问题不要只盯着总耗时。可以在导入循环里每写入 1 万条就记录一次耗时、堆使用量和 GC 次数，重点观察初始化参数调整前后的耗时曲线，看看之前的周期性抬升现象有没有消失。如果自定义容量之后尖峰消失，但 GC 反而变频繁，说明容量可能给得过大，要结合堆上限重新做平衡。

为什么扩容优化不能解决并发写入问题

HashMap 允许多个线程读取，但不提供并发写入的安全保证。两个线程同时执行 put，即使初始容量很大，也可能发生可见性问题、覆盖更新或结构状态不一致。把构造器改成 new HashMap(1_000_000) 只是在改变扩容时机，并没有改变容器的同步语义。

导入任务更稳妥的做法通常有两种：如果写入线程之间确实共享 key 空间，用 ConcurrentHashMap；如果每个分片可以独立处理，先让每个线程写自己的 HashMap，最后在单线程阶段合并。后者往往更容易控制锁竞争和失败重试。

把优化动作放回导入流程里验证

可以按下面顺序做一次小规模回归验证：先固定同一份输入文件，再分别测试默认构造、按估算容量构造、分片独立构造三组方案。每组记录导入总耗时、每万条耗时、峰值堆和最终条目数。最终条目数必须与业务侧去重规则一致，不能为了速度丢数据。

long start = System.nanoTime();
Map rows = new HashMap(133_334);
// 填充并校验 rows.size()
long elapsedMs = (System.nanoTime() - start) / 1_000_000;
System.out.printf("rows=%d, elapsedMs=%d%n", rows.size(), elapsedMs);

如果改完后仍然出现固定区间的性能尖峰，再查输入解析、对象创建逻辑和 GC 日志。扩容只是可能的影响因素之一，不要把所有导入抖动都直接归因于集合实现。

常见问题

HashMap 初始容量是不是直接写数据量就够了？

直接拿预计条目数当初始容量可不太行。还要考虑默认负载因子和内部向上取2次幂的规则。按预计条目数除以 0.75 再加少量余量，才更接近「达到目标规模前少扩容」的设计意图。

扩容会不会让 HashMap 里的 key 顺序改变？

会。HashMap 不承诺遍历顺序，扩容或哈希分布变化都可能让顺序不同。需要稳定顺序时，应明确使用 LinkedHashMap 等有顺序语义的实现。

多线程导入只读 HashMap 可以吗？

构建完成后只读通常比并发写安全得多，但发布给其他线程前仍要通过任务边界或安全发布机制建立可见性。构建阶段不要让多个线程直接写同一个 HashMap。

最后的判断

批量导入中看到周期性停顿，先用分段耗时和堆数据确认是否靠近扩容触发区间；数据量可估算时再调整初始容量。如果问题发生在并发写入场景，优先修正容器选择和数据分片逻辑，容量参数只能解决其中很小的一部分问题。