为什么 HashMap 中较高的负载因子会增加查找成本？答案

【问题标题】：Why would a higher load factor in HashMap increase lookup cost?为什么 HashMap 中较高的负载因子会增加查找成本？
【发布时间】：2012-08-20 18:01:09
【问题描述】：

来自HashMap的JavaDoc：

作为一般规则，默认负载因子 (.75) 提供了一个很好的时间和空间成本之间的权衡。较高的值会降低空间开销，但增加了查找成本（反映在大多数 HashMap类的操作，包括get和put）。

如果我们有更高的值，为什么会增加查找成本？

【问题讨论】：

@PaulTomblin 是负载因子 = 存储桶大小/键数？如果是这种情况，那么碰撞应该减少，因为增加负载因子意味着增加分子中的数量，前提是键的数量保持不变。
检查这个 [stackoverflow.com/questions/10901752/… [1]: stackoverflow.com/questions/10901752/…
@user1613360 你应该学会在评论中放一个链接。 Check this out 。顺便说一句，我在问这个问题之前已经看到了那个答案。它是 Javadoc 的复制/粘贴。

【解决方案1】：

这与 HashTable 如何在底层实现有关，它使用哈希码，并且由于计算哈希码的算法并不完美，您可能会遇到一些冲突，增加负载因子会增加发生冲突的概率，从而降低查找性能...

【讨论】：

【解决方案2】：

哈希表的Load Factor定义为

n/s，存储条目数n与表的桶数组大小s之比。

当冲突数量较少时，哈希表的高性能得以保持。当负载因子高时，存储相同数量的条目所需的哈希桶数保持较低，从而增加了冲突的概率。

【讨论】：

【解决方案3】：

默认负载系数 (0.75)。

If declare load factor as
1 the restructuring process only happens when number of elements are exceeding the capacity of the HashMap.

【讨论】：

【解决方案4】：

这里我们应该先了解一下容量和负载率是什么意思：

容量：这是在任何给定时间点任何哈希表中的桶数。

负载因子：负载因子是衡量哈希表在其容量自动增加之前允许达到的程度

因此，在容量增加之前，哈希表可能会占用更多的负载因子。

现在给出了 hashCode() 的最佳可能实现一个桶中只有一个值这里查找成本将是最小
在最坏的情况下，所有值都将放在同一个存储桶中，并且查找成本将最大
在平均情况中，这肯定取决于 hashCode() 实现，但这里还有一个因素是负载因子，集合占用的越多，将有可能发生碰撞，因此更高的负载因子会在非理想情况下增加查找成本。

【讨论】：

【解决方案5】：

负载因子 0.75 可以使用公式（n/s，存储条目数 n 与表的存储桶数组的大小 s 的比率。）这样解释：

假设你有 75 个值需要存储在哈希表中，并且你有 100 个空数组块来存储它们，这里冲突的机会被最小化并且负载因子为 0.75。

现在假设您有 75 个值要存储并且只有 10 个空数组块（负载因子 7.5），这意味着您将遇到冲突并采用任何会增加搜索时间的冲突解决技术。

现在你有 75 个条目和 1000 个空数组块（加载因子 0.075），这将导致很多空块，这会浪费很多空间。

因此，经验法则是，随着负载因子值的增加，您的搜索时间会增加，而当它接近 0 时，就会浪费更多的存储空间。

因此这是一个时空交易。

【讨论】：