要让hashmap一次性装下预估数据且不扩容，需按负载因子0.75反推最小容量：理论容量为⌈n/0.75⌉，再对齐到2的幂（如n=800→1067→2048）；直接传n（如new hashmap(800)）会导致实际容量1024，仅支持768个元素，第769次put即触发扩容。
初始化容量和加载因子设对了，HashMap 就不容易频繁扩容、哈希冲突也少，性能自然更稳。关键不是盲目调大，而是结合预期数据量和底层机制来算。
按预估元素数反推初始容量
默认初始容量是 16，但多数业务场景远不止存十几个键值对。如果预计放 N 个元素，又沿用默认负载因子 0.75，那初始容量至少得满足：
容量 × 0.75 ≥ N → 容量 ≥ N ÷ 0.75 ≈ N × 1.33
再向上取最接近的 2 的幂（HashMap 内部会自动对齐）。
- 比如预估存 100 个元素：100 × 1.33 = 133 → 最近的 2 的幂是 128？不对，128
- 预估存 500 个：500 × 1.33 ≈ 665 → 取 1024（2¹⁰）
- 直接写法：
new HashMap(256)或new HashMap(256, 0.75f)
加载因子一般不轻易改，除非有明确权衡
0.75 是空间与时间的平衡点：太小（如 0.5）浪费内存、扩容次数反而可能增多；太大（如 0.9）桶太满，链表/红黑树变长，get/put 耗时上升。只有在两类场景才考虑调整：
- 内存极度敏感且读多写少 → 可略提高到 0.8～0.85，但需实测冲突率
- 对查询延迟极其敏感（如金融实时风控）→ 可降到 0.6～0.7，用空间换稳定响应
- 别设成 1.0：虽然不触发扩容，但哈希冲突概率陡增，实际性能往往更差
注意容量必须是 2 的幂，否则会被自动修正
HashMap 底层靠 (n - 1) & hash 快速定位桶索引，这要求数组长度 n 是 2 的幂。你传入 100、200、1000 都没关系，内部会自动转成 128、256、1024。
- 传
new HashMap(100)→ 实际容量 = 128 - 传
new HashMap(128)→ 实际容量 = 128（刚好） - 没必要手动算 2 的幂，但知道它会被对齐，能帮你理解为什么推荐“略大于计算值”的整数
配合其他实践效果更好
光调容量和加载因子还不够，搭配这些更扎实：
- Key 类型尽量用不可变对象（如 String、Integer），避免哈希码中途变化导致查不到
- 自定义 key 时重写
hashCode()和equals()，且保证逻辑一致 - 如果 key 是复合对象，哈希算法要尽量分散（避免只依赖某一个字段）
- 高频读场景可考虑
ConcurrentHashMap，但它默认初始化逻辑类似，同样适用容量预估
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
