在 Java 中，HashMap 扩容时为什么选择容量为 2 的 n 次方倍？请解释其设计原理。

回答思路

1. 【回答框架 1】HashMap 的容量始终为 2 的 n 次方，这使索引计算 index = hash & (capacity - 1) 等价于取模运算，但位运算比取模更快，且当容量为 2 的 n 次方时，capacity - 1 的低位全为 1，可以直接用与运算提取 hash 的低位，减少哈希冲突。
2. 【回答框架 2】扩容时容量翻倍，即从 2^n 变为 2^(n+1)，元素的新位置要么在原索引，要么在原索引加旧容量处。这是因为扩容后 capacity - 1 多出一个高位 1，该位对应 hash 的相应位，根据该位是 0 还是 1 决定位置，无需重新计算每个元素的 hash，只需检查新增的那一位，提高了效率。
3. 【回答框架 3】在 JDK 1.8 中，当链表长度超过阈值（8）且容量不小于 64 时，链表转为红黑树，但容量仍保持 2 的 n 次方，位运算优化依然适用。此外，2 的 n 次方容量还能使扩容后元素分布相对均匀，降低冲突概率。
4. 【回答框架 4】从性能角度看，位运算与取模在结果上等价，但位运算直接作用于 CPU，节省了除法指令，尤其在频繁插入和扩容场景下，这种优化能减少计算开销，是空间和时间的权衡设计。
5. 【关键点 1】容量为 2 的 n 次方使索引计算 hash & (capacity - 1) 等价于取模，但速度更快。
6. 【关键点 2】扩容时元素位置要么不变，要么加旧容量，根据新增的 hash 位判断，无需重哈希。
7. 【关键点 3】位运算优化提升了 HashMap 在插入和查找时的效率，尤其在高并发或大数据量场景下优势明显。
8. 【易错点 1】误认为 2 的 n 次方是为了避免哈希冲突，实际上主要为了位运算优化，冲突还与 hash 函数有关。
9. 【易错点 2】忽略当容量非 2 的 n 次方时，取模运算需要除法，性能下降，且无法直接利用位运算特性。
10. 【易错点 3】仅提红黑树转换而忽略容量倍数的前提，例如链表转红黑树的条件是容量不小于 64，否则可能先扩容。