大厂规范要求手动指定hashmap初始容量以避免频繁扩容带来的性能损耗，需根据预期元素数÷0.75向上取整再对齐到2的幂，平衡空间与时间开销。
大厂规范要求手动指定 HashMap 初始容量，核心是为了规避频繁扩容带来的性能损耗，而不是“必须”——它不强制语法层面的编译错误，但属于关键性能实践。
扩容代价远超想象
HashMap 每次扩容都要：重新分配所有已有元素的位置（rehash）、新建更大数组、逐个迁移节点。这个过程是 O(n) 时间复杂度，且伴随内存抖动和 GC 压力。例如：未指定容量插入 1024 个元素，resize 会触发约 8 次；若插入千万级数据，可能触发数十次，耗时成倍增长。
默认容量（16）严重脱离多数业务场景
16 是通用兜底值，但实际业务中极少恰好需要存 12 个以内元素（16 × 0.75 = 12 是首次扩容阈值）。更多情况是：存几十个配置项、上百个用户会话、上千条订单缓存——这些都远超 16，却仍被默认容量“拖慢起步”。不指定，等于主动接受至少一次扩容。
初始容量不是填预期数量，而是反推阈值
直接写 new HashMap(100) 并不会让容量变成 100。JDK 会自动向上取整到最近的 2 的幂（即 128），而真正决定何时扩容的是 threshold = capacity × loadFactor（默认 0.75）。所以合理公式是：
- 预期元素数 ÷ 0.75 + 1（向上取整）→ 得到理论最小 capacity
- 再由 JDK 自动对齐为 2 的幂（如预期 100 个 → 100 ÷ 0.75 + 1 ≈ 134 → 取 128 或 256）
这样可确保 threshold ≥ 预期 size，极大降低扩容概率。
空间与时间的显性权衡
指定过大容量（如预估 100 却设 1024）会浪费内存；过小（如预估 1000 却用默认 16）则频繁扩容。规范强调“指定”，本质是推动开发者做一次轻量级预判——哪怕粗略估算，也比完全忽略强。这在高并发、低延迟系统中尤为关键。
