翻倍扩容确保容量始终为2的幂，使hash&(capacity-1)寻址高效且正确，重哈希仅需判断一个高位bit，兼顾性能与内存效率。
因为翻倍扩容能配合位运算实现高效重哈希，避免取模开销，同时保持容量始终为 2 的幂次方，这是 HashMap 底层寻址机制的硬性要求。
位运算寻址依赖 2 的幂次方
HashMap 计算数组下标用的是 hash & (capacity - 1)，而不是 hash % capacity。这个技巧只有在 capacity 是 2 的幂时才成立——此时 capacity - 1 的二进制全是 1（比如 16−1 = 15 → 0b1111），按位与操作等价于取低 N 位，速度快且分布均匀。如果容量不是 2 的幂，就无法用该公式，必须回退到慢得多的取模运算。
翻倍让重哈希只需判断一个高位 bit
扩容从 16→32 时，新旧容量差值正好是旧容量（32−16 = 16）。这时每个元素的新位置只取决于哈希值中“对应旧容量最高位”的那个 bit：
- 如果该 bit 是 0，新下标 = 旧下标
- 如果该 bit 是 1，新下标 = 旧下标 + 旧容量
不需要重新调用 hashCode() 或完整重算 hash，仅靠一次位与就能完成分流，大幅降低迁移成本。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
保证扩容后仍满足 2 的幂约束
初始容量默认是 16（2⁴），每次 ×2 后仍是 2⁵、2⁶、2⁷……始终维持 2 的幂结构。这个性质不是为了“整齐”，而是整个哈希定位、扩容迁移、树化阈值判断等逻辑正常运转的前提。一旦破坏（比如扩为 24 或 48），底层位运算会失效，导致下标错乱、元素丢失或死循环。
兼顾空间与时间的折中选择
翻倍不是唯一可能（比如 ×1.5 也能保持某些特性），但它是工程上最平衡的方案：
- 太慢（如 ×1.2）→ 扩容频繁，rehash 开销累积严重
- 太快（如 ×4）→ 内存浪费明显，且高位判断逻辑变复杂
- ×2 刚好使新旧容量间只差 1 个 bit，迁移逻辑最简，硬件友好
