HashMap 的长度为什么是 2 的幂次方？

[$ÿĀ]陌年微凉

于 2024-03-29 12:53:42 发布

阅读量340

点赞数 5

文章标签： java 哈希算法开发语言

本文链接：https://blog.csdn.net/qq_52594679/article/details/137141667

版权

GPT4.0回答

如果您需要使用免费的gpt4.0
免费的gpt4.0 https://api.fukaluosi.online

高效的索引计算：当数组长度是 2 的幂时，通过位运算替代模运算来计算元素索引变得可能。位运算比模运算效率高很多。对于一个长度为 2^n 的数组，计算元素索引的公式可以从 index = hash % (arrayLength) 简化为 index = hash & (arrayLength - 1)，其中 & 是位与操作。因为 arrayLength - 1 的二进制表示中，低位全是 1，这样可以直接用 hash 值的低 n 位作为数组索引，实现快速定位。
减少哈希碰撞：如果数组的长度是 2 的幂，使用合适的哈希函数可以减少哈希碰撞的概率。这是因为，如果哈希码分布均匀，那么通过上述位运算得到的索引也将尽量分散，从而使得键值对在 HashMap 的内部数组中分布得更加均匀。
扩容均匀：当 HashMap 需要扩容时，新数组的大小也是 2 的幂次方，这样能够保证在扩容过程中，原有的元素可以均匀地分布在新的数组中。如果数组的大小不是 2 的幂，那么在扩容时可能会出现分布不均的情况，进一步增加哈希碰撞的可能性。

除此之外的额外回答如下：

除了之前提到的为了高效的索引计算、减少哈希碰撞和扩容均匀性外，HashMap 的长度设计为 2 的幂次方主要还基于以下几点考虑：

1. 扩容效率
在 HashMap 中，当元素数量达到容量与负载因子的乘积时，HashMap 会进行扩容，新的容量是原容量的两倍（即保持为 2 的幂次方）。这种设计使得在扩容时，原有的数据重新哈希分布到新的桶位中时，只需判断哈希值在新旧容量下的差异位，而不需要重新计算整个哈希值，从而提高了扩容的效率。

2. 优化内存访问
计算机的存储系统（尤其是缓存系统）通常优化了连续内存块的访问速度。当 HashMap 的大小为 2 的幂次方时，其数据结构的内存布局趋向于与这些系统的设计相匹配，从而可能在实际运行中获得更好的性能。

3. 通用性和可预测性
通过维持 2 的幂次方作为容量，HashMap 提供了一种通用而可预测的扩展机制。因为这种设计简单明了，它帮助开发者在理解和预测 HashMap 行为方面提供了便利，尤其是在性能调优和容量规划方面。

4. 兼容历史
Java 中 HashMap 的这种设计也部分受到了历史版本和其他语言实现中类似数据结构设计的影响。在给定的环境下，保持这种设计有助于维护代码的兼容性和开发者的预期。

总结来说，HashMap 长度选择为 2 的幂次方，是基于提升其索引计算的效率、减少哈希碰撞、保持扩容的均匀及效率、以及优化内存访问等多方面的综合考虑。这种设计使得 HashMap 在处理大量数据时能保持较高的性能和较好的可预测性，满足广泛的使用场景。

计算索引时效率更高： hash % tab.length，而计算机中直接求余运算效率不如位移运算。所以源码中做了优化，使用 hash & (tab.length- 1)来寻找桶位。而实际上 hash % length 等于 hash & ( length - 1) 的前提是 length 必须为 2 的 n 次幂
扩容时重新计算索引效率更高： hash & oldCap == 0 的元素留在原来位置，否则新位置 = 旧位置 + oldCap
当根据 key 的 hash 值寻址计算确定桶位下标 index 时，如果HashMap 的数组长度 tab.length 是 2 的 n 次幂数，那么就可以保证新插入数组中的数据均匀分布，每个桶位都有可能分配到数据，而如果数组长度不是 2 的 n 次幂数，那么就可能导致一些桶位上永远不会被插入到数据，反而有些桶位频繁发生 hash 冲突，导致数组空间浪费，冲hash 突概率增加。

看的不明白的可以观看下图解链接https://blog.csdn.net/u012501054/article/details/103710171