hashmap默认初始容量为16、负载因子为0.75，是空间利用率与查询性能权衡的工程最优解：16为2的幂以支持高效位运算索引计算，且兼顾避免过早扩容与内存浪费；0.75则平衡哈希冲突概率与内存使用率，使首次扩容阈值为12，保障o(1)平均查找性能。
HashMap 默认初始容量设为 16、负载因子设为 0.75，不是随意定的 magic number，而是工程实践中对查询性能、内存占用和扩容开销三者反复权衡后的最优解。
为什么容量必须是 2 的幂？
HashMap 计算数组索引用的是位运算：index = (length - 1) & hash，这比取模 hash % length 快 5~8 倍。但该公式成立的前提是 length 必须是 2 的幂（如 4、8、16、32）。否则位运算结果会偏离真实取模值，导致元素错位或无法命中。
所以无论你传入 new HashMap(10) 还是 new HashMap(19)，内部都会自动向上取整到最近的 2 的幂——也就是 16。
为什么选 16 而不是更小或更大？
- 太小（比如 4 或 8）：插入 3–6 个元素就触发扩容，频繁 rehash 显著拖慢写入性能；
- 太大（比如 32 或 64）：空桶过多，内存浪费明显，对中小规模业务（如缓存几十个配置项）不友好；
- 16 是经验平衡点：常见业务场景下，能容纳约 12 个键值对再扩容，既避开过早扩容，又不显著增加 GC 压力。
为什么负载因子是 0.75 而不是 0.5 或 1.0？
负载因子决定「什么时候扩容」，本质是在哈希冲突概率和内存使用率之间找折中：
- 设为 1.0：空间用满才扩容，内存最省，但桶平均负载接近 1，碰撞激增，链表变长，查找退化为 O(n)；
- 设为 0.5：冲突极少，查询极快，但刚用一半就扩容，空间浪费 50%，且扩容次数翻倍，rehash 总耗时反而上升；
- 0.75 对应阈值 16 × 0.75 = 12：此时桶平均负载约 0.75，绝大多数桶为空或仅 1 个元素，链表极短，红黑树几乎不触发，O(1) 查找概率高。
容量与负载因子是协同设计的
16 和 0.75 是配套参数，不是孤立设定：
- 首次扩容门槛固定为 12，给小数据量提供稳定窗口；
- 扩容后容量翻倍（16 → 32 → 64…），始终维持 2 的幂，位运算逻辑持续有效；
- 延迟扩容策略把 rehash 开销摊薄——不是每次 put 都动，而是等填到 75% 再集中处理。
如果你明确知道要存上千个键值对，建议直接指定初始容量，例如 new HashMap(1024)，跳过多轮扩容，提升初始化效率。
