HashMap默认初始容量为16、负载因子为0.75，是空间利用率与查询性能权衡的工程最优解：16为2的幂以支持高效位运算索引计算，且兼顾避免过早扩容与内存浪费；0.75则平衡哈希冲突概率与内存使用率，使首次扩容阈值为12，保障O(1)平均查找性能。
HashMap 默认初始容量设为 16、负载因子设为 0.75，是空间利用率与查询性能之间长期权衡得出的工程最优解，不是随意指定的 magic number。
为什么初始容量是 16？
容量必须是 2 的幂，这是为了用位运算 h & (length - 1) 快速替代取模运算 h % length，提升索引计算效率（位运算比取模快 5~8 倍）。而 16 是一个经验平衡值：
- 太小（如 4 或 8）：插入少量元素就触发扩容，频繁 rehash 拖累性能；
- 太大（如 32 或 64）：空桶过多，浪费内存，且对小数据量场景不友好；
- 16 在常见业务数据规模下，既避免过早扩容，又不过度占用堆内存。
另外，HashMap 构造时若传入非 2 的幂容量（比如 10），内部会自动向上取整到最近的 2 的幂（即 16），确保底层始终满足位运算前提。
为什么负载因子是 0.75？
负载因子 = 触发扩容的元素数量 / 当前数组长度。它本质是在「哈希冲突概率」和「内存使用率」之间找平衡点：
- 设为 1.0：空间用满才扩容，内存利用率最高，但大量哈希碰撞导致链表变长，查询退化为 O(n)，红黑树转化压力大；
- 设为 0.5：冲突极少，查询接近 O(1)，但容量刚用一半就扩容，空间浪费严重，且扩容次数翻倍，rehash 开销剧增；
- 0.75 是实验与理论推导的折中：16 × 0.75 = 12，即插入第 13 个元素时扩容；此时平均每个桶约存 0.75 个元素，冲突可控，链表普遍很短，整体仍维持较高 O(1) 查找概率。
两者协同工作的效果
初始容量 16 和负载因子 0.75 是配套设计：
- 第一次扩容阈值固定为 12，给了小规模数据稳定运行窗口；
- 扩容后容量翻倍（16 → 32 → 64…），保证新数组仍为 2 的幂，位运算逻辑持续生效；
- 每次扩容都重新 hash 所有键，虽然耗时，但通过延迟扩容（等填到 75% 再动）把这种开销摊薄到合理范围。
如果明确知道要存几千个键值对，建议构造时显式指定初始容量（如 new HashMap(1024)），可跳过多次扩容，提升初始化性能。
