hashmap初始容量设为2的幂次方，是为了用hash&(capacity−1)位运算高效替代取模、保证索引均匀分布、支撑扩容时的高位迁移优化；即使传入非2的幂（如10），也会自动对齐到最近的2的幂（如16）。
HashMap 的初始容量设为 2 的幂次方，核心目的是为了高效、均匀地将键映射到数组索引上，避免取模运算开销，并减少哈希冲突。这不是强制规定（构造函数允许传入任意正整数），但 HashMap 会自动将其“向上对齐”到最近的 2 的幂次方。
提高索引计算效率：用位运算替代取模
HashMap 底层用数组存储桶（bucket），元素位置由 hash & (capacity - 1) 算出。这个公式仅在 capacity 是 2 的幂时才等价于 hash % capacity。
例如：capacity = 16（即 2⁴），capacity − 1 = 15，二进制是 1111。那么 hash & 15 就相当于只保留 hash 的低 4 位——效果和 hash % 16 完全一致，但位运算是 CPU 级原语，比除法取模快得多。
如果容量是 15（非 2 的幂），15 的二进制是 1111，但 15−1=14（1110），hash & 14 会错误地清零某些位，导致索引分布严重不均，甚至大量索引永远无法被命中。
保证索引范围合法且全覆盖
当 capacity 是 2 的幂时，capacity − 1 的二进制全是 1（如 31→11111），与 hash 做按位与，结果必然落在 [0, capacity−1] 范围内，且只要 hash 值本身分布尚可，低位变化就能充分影响结果。
若 capacity=10（非幂），10−1=9（1001），hash & 9 会强制让第 1 位和第 3 位（从 0 开始）以外的位失效，导致：
- 大量不同 hash 映射到同一索引（比如 hash=1、9、17、25 都得 1）
- 索引 2、4、5、6、7 等可能长期空置
- 实际可用桶数远低于容量，负载率虚高，提前触发扩容
支撑扩容时的“高位迁移”优化
当 HashMap 扩容（如从 16→32），新容量仍是 2 的幂，此时每个旧桶中的节点只需根据 hash 的新增高位（第 5 位）决定去新数组的 “原位置” 还是 “原位置 + 旧容量”。这个判断只需 (e.hash & oldCap) == 0，一次位运算即可完成分组。
该优化依赖新旧容量均为 2 的幂——否则无法通过单个 bit 判断迁移方向，必须重新计算全部 hash 和索引，性能大幅下降。
Java 实际做了兜底处理
即使你传 new HashMap(10)，HashMap 构造函数内部会调用 tableSizeFor(10)，返回 16；传 100 → 返回 128。所以你几乎不可能让底层 table 容量真正变成非 2 的幂。
这个设计不是为了“限制用户”，而是把复杂性封装起来：确保无论用户怎么设，底层都能获得最优的散列行为和运行效率。
