最稳妥做法是根据预期元素数量计算：capacity ≥ expectedsize / 0.75，再向上取最近的2的幂；因hashmap强制将传入容量调整为≥该值的最小2的幂（如传20→32），且扩容触发条件为size ≥ capacity × 0.75，避免插入中resize需确保预期元素数不超过阈值。
直接根据预期元素数量反推，再向上取最近的 2 的幂，是最稳妥的做法。关键不是“设多大”，而是“避免在插入过程中触发扩容”。
为什么初始容量不能随便写？
HashMap 内部容量必须是 2 的幂（如 16、32、64、128…），你传入的 initialCapacity 只是提示值，JDK 会自动调用 tableSizeFor() 计算出第一个 ≥ 该值的 2 的幂作为真实容量。比如传 20 → 实际容量为 32；传 15 → 实际为 16。
而扩容阈值 = 容量 × 负载因子（默认 0.75）。一旦 put 元素后 size ≥ 阈值，就会触发 resize —— 全量 rehash、新建数组、逐个迁移节点，开销很大。
所以设小了会频繁扩容；设太大又浪费内存（尤其是大量空桶）。
怎么算出合理的初始容量？
目标是：让 预期元素数量 ≤ 阈值，即
expectedSize ≤ capacity × 0.75
移项得：capacity ≥ expectedSize / 0.75 ≈ expectedSize × 1.333…
再向上取最近的 2 的幂即可。常用做法是：
- 按公式算：
(int)(expectedSize / 0.75f) + 1（+1 是防整除后刚好踩线） - 对结果调用
Integer.highestOneBit(x * 2)或直接查表/心算找 2 的幂 - 例如：预计存 1000 个元素 → 1000 / 0.75 ≈ 1333.3 → +1 = 1334 → 最近的 2 的幂是 2048（2¹¹）
- 再验证：2048 × 0.75 = 1536 > 1000，安全；若选 1024 → 阈值仅 768，第 769 个元素就会扩容
常见误设场景提醒
这些写法看似合理，实则容易翻车：
-
new HashMap(100)→ 实际容量 128，阈值 96 → 存到第 97 个就扩容 -
new HashMap(expectedSize)→ 比如 expectedSize=12，传 12 → 容量变 16 → 阈值 12 → 第 12 个元素插入时就触发扩容（临界点） -
new HashMap(4)存 4 个用户字段 → 容量 4 → 阈值 3 → 插入第 4 个即扩容，比默认 16 还差
阿里规范推荐的公式 (expectedSize / loadFactor) + 1 就是为了避开这种“刚踩阈值”的情况。
要不要改负载因子？
一般不建议。0.75 是时间与空间的平衡点：
- 设成 0.5：阈值减半 → 更早扩容 → 内存更省但性能更差
- 设成 0.9：阈值提高 → 扩容延迟 → 但哈希冲突概率上升，链表/红黑树操作增多，平均查找变慢
- 除非你明确压测过且有收益，否则保持默认即可
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
