java hashmap 默认初始容量为16，因其是2的幂，可使索引计算index = hash & (capacity - 1)高效替代取模，且在性能、内存与扩容频率间取得工程平衡；预估元素数n时，应取≥ceil(n/0.75)的最小2的幂。
Java HashMap 默认初始容量设为 16，不是随意定的，而是兼顾索引计算效率、内存占用和扩容频率的工程平衡结果。设置初始容量的关键是匹配真实数据规模，避免频繁扩容或浪费内存。
为什么是 16？核心在位运算和经验权衡
HashMap 底层用数组存桶，索引通过 index = hash & (capacity - 1) 计算。这个公式能替代取模（hash % capacity），但前提是 capacity 必须是 2 的幂——只有这样，capacity - 1 的二进制才全是 1，位运算才能准确截取低位哈希值。
选 16（即 2⁴）是因为：
- 太小（如 4 或 8）：刚插几个元素就触发扩容，rehash 开销大，写入性能差；
- 太大（如 32 或 64）：空桶多，小数据量时内存明显浪费；
- 16 在多数轻量场景下够用，又不会显著增加内存压力，是长期实测验证的折中点。
怎么合理设置初始容量？按预估数量反推
目标是让元素填入后不触发首次扩容。默认负载因子是 0.75，所以扩容阈值 = 容量 × 0.75。要放 n 个元素，推荐：
- 先算理论最小容量：(int) Math.ceil(n / 0.75)；
- 再取大于等于该值的最近 2 的幂（JDK 内部自动完成，你传 14，它变成 16；传 134，它变成 256）；
- 例如：预计存 100 个键值对 → 100 ÷ 0.75 ≈ 133.3 → 向上取整为 134 → 最近 2 的幂是 256。
小规模（≤16 个元素）直接用默认构造即可，没必要显式指定。
什么情况下不该手动设初始容量？
不是所有场景都适合硬编码容量：
- 元素数量波动大或无法预估（比如缓存、实时聚合结果）；
- 集合生命周期短、只用一两次（如方法内临时 Map）；
- 代码可读性和维护性比微秒级性能更重要；
- 盲目设过大（如直接传 10000）会浪费内存，设过小又频繁 resize——关键是贴合真实负载。
更省心的写法：用 Guava 工具类
Guava 提供了开箱即用的封装，内部已实现标准计算逻辑：
Map<string integer> map = Maps.newHashMapWithExpectedSize(100);</string>
它会自动按 (expectedSize / 0.75) + 1 算出合适容量，兼容边界情况，比手算更稳妥。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
