在排查性能问题时，HashMap 扩容引起的停顿往往容易被忽略。尤其当集合存储大几千到百万级别的元素时，扩容操作涉及重新哈希和复制整个数组，耗费的时间会随着集合大小上升而明显增长。因此，初始化时指定一个合理的 initialCapacity 是减少扩容次数、提升性能的重要手段。但盲目设大或设小都可能带来反效果，下面具体说明判断路径和操作方式。

先确认扩容风险

HashMap 的默认初始容量是 16，负载因子是 0.75。当元素数量超过容量与负载因子的乘积时，会触发扩容，每次扩容为原来的两倍。扩容操作涉及重新计算哈希和复制元素，消耗较大。因此，如果预知存储元素数量，应通过 initialCapacity 指定一个初始值，使得扩容次数尽可能少。但并非直接传入预期的元素个数，因为实际容量会被调整为 2 的幂次方，且扩容阈值是基于当前容量乘以负载因子计算的。

在执行代码审查或排查 OOM 问题时，可以先观察 HashMap 的初始化处是否指定了容量。如果看到类似 new HashMap<>() 而预期元素数已知且较大，那就需要标记为风险点。尤其是循环插入、批量入库等场景，扩容开销可能放大数十倍。

如何计算合适的初始容量

如果已经确定风险点，下一步就是给出正确的初始容量。有一个广泛使用的计算公式，其来源是 HashMap 本身的阈值逻辑：

为了减少扩容，推荐使用公式：initialCapacity = (int)(expectedSize / 0.75f) + 1。这个公式源自 HashMap 的阈值计算公式（容量 * 负载因子）。例如，预期存储 100 个元素，代入得初值 134，实际容量会被 HashMap 内部调整为 256（2 的幂），对应的阈值为 192，远远大于 100，从而避免或减少扩容。如果不加 1 直接取整，可能因容量被调整而出现容量略大于期望但阈值仍不足的情况。

实现时可以直接这样写：

int initialCapacity = (int)(expectedSize / 0.75f) + 1;
Map<String, Object> map = new HashMap<>(initialCapacity);

需要注意，expectedSize 应该是你确信不会超过的最大元素数量，而不是平均值。如果预估不准确，容量偏小仍有扩容风险，偏大则浪费内存。

容量过大反而有代价

有些开发者为了避免扩容，会设置一个很大的初始容量，比如 100 万。但过大的容量会浪费内存，因为 HashMap 的内部数组长度就是指定的容量（2 的幂），即便没有存储元素，也会占用相应内存。此外，创建时指定过大的容量还会延长遍历和哈希计算的耗时。正确的做法是：根据预期最大元素数量，使用公式计算出合理的初始容量，既不过大也不过小。

举个例子：如果预期元素数是 1000，按公式得到 initialCapacity 约为 1334，实际容量被调整为 2048，占内存约 8KB（指针压缩下）。如果直接给 1000000，数组长度变成 1048576，内存占用增加约 512 倍，而实际上可能只用了千分之一，显然不合理。

验证方法：日志与反射

修改后如何在测试环境确认改动生效？有几种思路：

• 打印扩容日志：通过继承 HashMap 并重写 resize 方法，在扩容时输出当前容量、新容量、元素数等信息。这样可以观察是否还有扩容发生。
• 反射读取 threshold：虽然 HashMap 的 threshold 字段不是 public，但可以通过反射在初始化后读取该值，确认是否足够覆盖预期数量。例如：

Field thresholdField = HashMap.class.getDeclaredField("threshold");
thresholdField.setAccessible(true);
int threshold = thresholdField.getInt(map);

读取后与预期元素数对比，若阈值 > 预期元素数，则扩容不会发生。

• 观察 GC 和内存：在压测中查看 GC 次数和停顿时间，扩容动作会伴随大量临时对象，如果优化后此类停顿明显减少，说明初始容量设置合理。

回滚边界：如果修改后发现在某些场景下内存上升较多且插入性能变差（如频繁插入少量元素），可以回退到默认值或减小容量。通常，只要公式计算无误，不需要回滚。

其他集合的类似优化

不仅 HashMap，ArrayList 也有类似机制。ArrayList 的默认初始容量是 10，扩容时增长为原来的 1.5 倍。如果预知元素数量，应使用构造函数指定容量，避免反复扩容。对于 HashSet，其内部基于 HashMap，所以初始容量设置方式相同。而对于 TreeMap 或 LinkedHashMap，它们没有类似的容量参数，但可以通过预先分配内部数组的方式间接优化（如使用 ConcurrentHashMap 的 initialCapacity 参数）。

处理时可以根据集合类型分别检查：

• ArrayList：使用 new ArrayList<>(expectedSize)，注意按实际大小设置，不要预留过多。
• HashSet：参考 HashMap 公式，因为内部是 HashMap，new HashSet<>(initialCapacity) 有效。
• ConcurrentHashMap：同样有 initialCapacity 参数，但它的内部实现略有不同，但公式依然适用（基于相同阈值原理）。

如果遇到没有容量参数的集合（如 TreeMap），可以通过预填充（例如提前放入占位元素再清除）来触发内部结构调整，但这比较 hack，不推荐在稳定代码中使用。更保守的做法是评估元素数量是否真的需要优化，如果元素数少于几千，默认容量通常足够。

边界与注意事项

公式中的除法涉及浮点运算，在 Java 中直接写 (int)(expectedSize / 0.75f) + 1 即可。如果 expectedSize 很大（比如超过 Integer.MAX_VALUE / 0.75），要注意整数溢出，但实际场景中很少出现。另一个小细节：如果 expectedSize 为 0，公式给出 (int)(0/0.75f) + 1 = 1，实际容量变成 1，但 HashMap 内部会调整为 2？实际上，容量为 0 时构造函数会处理为 1，然后再调整到 2 的幂——1 已经是 2 的 0 次方，所以最终容量是 1。这种情况下不如直接用默认构造，因为默认扩容阈值 12 对于少量元素更灵活。因此，当 expectedSize 很小（比如 ≤ 12）时，可以不指定容量。

另外，公式只适用于负载因子保持默认 0.75 的情况。如果自定义负载因子，需要相应调整。

每次修改前，先记录当前 HashMap 的初始声明位置、预期元素数、是否有多线程并发（ConcurrentHashMap 另有调整），修改后在单元测试或集成测试中验证插入完预期元素后没有扩容日志即可。