我要评论 在 java 开发中，hashmap 是最常用的集合类之一，性能高效、使用灵活。然而它的底层实现并不简单，尤其涉及扩容、哈希冲突与负载因子等关键概念时，往往容易理解模糊。
本文将聚焦以下三个问题，深入剖析 hashmap 的核心设计：
- hashmap 的负载因子是什么？
- 为什么默认值是 0.75？
- 扩容时 hash 值不变，为什么能减少冲突？
一、什么是 hashmap 的负载因子？
在 hashmap 中，负载因子（load factor） 是一个用于衡量哈希表空间使用紧凑程度的重要参数。它直接影响何时触发扩容，进而影响内存使用与查询性能。
定义：
负载因子 = 当前存储的键值对数量 / 哈希桶数组长度
当负载因子达到设定的阈值时，hashmap 会自动进行扩容操作：新建一个容量更大的数组，并将原有的键值对重新分布（rehash）到新数组中。
源码解析
在 java.util.hashmap 类中，默认负载因子为：
static final float default_load_factor = 0.75f;
也就是说，在没有显式指定的情况下，默认在填满 75% 时进行扩容。
你也可以在创建 hashmap 时自定义负载因子：
public hashmap(int initialcapacity, float loadfactor) {
if (initialcapacity < 0)
throw new illegalargumentexception("illegal initial capacity: " + initialcapacity);
if (loadfactor <= 0 || float.isnan(loadfactor))
throw new illegalargumentexception("illegal load factor: " + loadfactor);
this.loadfactor = loadfactor;
...
}
是否建议自定义负载因子？
大多数场景下，我们不建议手动修改负载因子，保留默认值 0.75 即可，这已经是基于性能与内存平衡的最优设定。
但在以下场景中，你可以根据业务特点进行调整：
- 如果你希望降低内存使用，且可接受一定程度的查找性能下降，可以适当提高负载因子（如
0.9）。 - 如果你更看重查找性能、希望减少冲突，可以降低负载因子（如
0.5），但要注意会更频繁地触发扩容，占用更多内存。
总结：默认值已经非常理想，仅在对性能有特别需求的场景下才需手动调整。
二、为什么默认负载因子是 0.75？
你可能会好奇：为什么不是 0.5？也不是 1？为什么偏偏选了一个看似“奇怪”的小数：0.75？
这是 hashmap 中非常经典的一个设计权衡，背后其实包含了对时间复杂度与空间浪费之间的精准平衡。
1. 若负载因子过小（如 0.5）
优点：冲突概率低，查找性能好（链表更短）
缺点：空间利用率低，hashmap 扩容频繁，内存占用大，影响 gc
2. 若负载因子过大（如 0.9 ~ 1）
优点：节省内存，提高桶使用率
缺点：冲突率高，大量键落在同一桶上，形成链表或红黑树，查找效率急剧下降
3. 0.75 是如何确定的？
这个值来自 java 官方的实证研究与工程测试，它在以下几个方面达到了一个黄金折中：
- 哈希冲突控制在合理范围
- 平均查找效率接近常数级 o(1)
- 扩容频率不会太高
- 内存利用率可接受
简而言之，0.75 是“性能”和“内存”之间最理想的平衡点，因此被设为默认值。
三、hashmap 扩容时 hash 值不变，为何却能有效减少冲突？
在研究 hashmap 的扩容机制时，一个常见且看似矛盾的问题是：
hash 值在扩容前后保持不变，为什么元素却可能不再冲突？新的槽位是怎么确定的？
这个问题的关键在于：虽然 hash 值本身没有变化，但用于计算桶索引的掩码发生了改变。
下面我们通过一系列步骤来彻底解析这一机制。
1. hashmap 如何根据 hash 值定位桶位置？
hashmap 中的元素是存储在“桶”（即数组的每一项）中的，而桶的索引通过如下位运算计算：
index = (n - 1) & hash
其中：
n是当前数组的长度，必须是 2 的幂（如 16、32、64）。hash是 key 的哈希值。&是按位与操作，作用是取hash的低位，用作索引。
为什么使用 (n - 1) & hash 而不是 hash % n？
因为 (n - 1) 在 n 为 2 的幂时，会恰好生成一个形如 01111... 的掩码，这种掩码与 hash 做位与，可以高效地截取 hash 的低位，从而避免性能损耗。
举个例子：
假设 hash = 100010（二进制，十进制 34） 数组容量 n = 16 ⇒ n-1 = 01111（二进制，十进制 15） 计算索引： index = 100010 & 01111 = 00010（二进制，十进制 2）
2. 扩容后发生了什么？
当 hashmap 扩容（例如从 16 扩到 32）时，数组长度 n 变为 32，对应掩码 n - 1 = 31 的二进制形式为 11111，比原来的掩码多了一位。
继续看上面的 hash 值 100010：
扩容前：100010 & 01111 = 00010 = 2 扩容后：100010 & 11111 = 10010 = 18
同一个 hash 值，扩容后计算出的桶索引发生了变化。现在它们被分配到不同的槽位，冲突被成功消除！
这也就解释了为什么扩容后能减少冲突？
关键在于：
掩码变长，能够利用 hash 中更多的位数参与索引计算，从而进一步区分不同的 key。
在数组容量较小时，很多不同的 key 可能因为 hash 值的低位相同而映射到同一个槽位上，发生碰撞。而扩容后，掩码“多了一位”，可以“看见”更多的 hash 信息，从而把这些 key 区分开。
3. java 8 如何高效进行“是否迁移”判断？
在 java 8 的 hashmap 实现中，扩容时并不重新计算完整的 hash，而是通过以下位运算快速判断一个元素是否应迁移到新位置：
if ((hash & oldcap) == 0) {
// 保持在原位置
} else {
// 移动到原位置 + oldcap 的新位置
}
这个技巧源于：
- 新容量是旧容量的 2 倍；
- 所以新掩码只是多了一位；
- 只要检查 hash 的这一位是 0 还是 1，就能判断是否需要迁移。
这种方式既简洁又高效，避免了重新计算 hash 值。
小结：
- 扩容不会改变 hash 值，但会改变参与索引计算的掩码；
- 掩码变长，相当于 hash 值的“参与者”更多，精度更高；
- 原本冲突的 key 可能被分到不同的槽位，冲突自然减少；
- java 8 通过位运算快速判断元素是否需要迁移，提高扩容效率。
四、总结：三个关键问题，一次性搞懂
本文围绕 hashmap 的核心机制，从源码出发，系统解答了以下三个常见却重要的问题：
1. hashmap 的负载因子是什么？
负载因子（load factor）是衡量 hashmap 空间使用率的重要参数，决定了 “何时触发扩容”。
默认值：0.75，即当实际元素数量达到容量的 75% 时进行扩容。
2. 为什么默认是 0.75？
这是一个在 性能与空间利用之间的黄金折中点：
值太小：空间浪费，数组利用率低；
值太大：冲突增多，查找效率下降。
0.75 是基于大量实践经验得出的经验值，能在多数场景下实现最优平衡。
3. 扩容时 hash 值不变，为什么冲突减少了？
虽然 hash 值本身不变，但扩容后：
数组容量变为原来的 2 倍；
掩码（n - 1）位数增加；
更多 hash 位参与索引计算；
原本由于 hash 低位相同而落入同一槽位的 key，现在可被区分到不同槽位，有效降低冲突概率。
一句话总结：
hashmap 的设计，不靠复杂算法，而是靠“合理的位运算 + 精妙的扩容策略”来在效率与空间之间取得最佳平衡。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论