为什么HashMap中更高的加载因子会增加查找成本？

Question

来自HashMap的JavaDoc：

  

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

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

Answer 1

哈希表的Load Factor定义为

  

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

当冲突次数较少时，保持哈希表的高性能。当负载系数很高时，碰撞的概率会增加。

Answer 2

它与如何在引擎盖下实现HashTable有关，它使用哈希码，并且由于算法计算哈希码并不完美，因此可能会发生一些冲突，增加负载因子会增加发生冲突的可能性，并因此降低查找性能......

Answer 3

在这里，我们应该首先了解容量和负载因子的含义：

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

负载系数：负载系数是衡量哈希表在其容量自动增加之前可以获得多长的度量

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

• 现在给出hashCode（）的最佳实现只有一个值将放在一个桶中这里查找成本将最小
• 在最坏的情况下，所有值都将在同一个存储桶中，查找成本将最大值
• 在平均情况中，这肯定会依赖于hashCode（）实现，但是这里将要发挥的另一个因素是加载因子，随着收集的占用越多，越多将会有碰撞的机会，因此在非理想情况下，更高的载荷因子会增加查找成本。

Answer 4

默认加载系数（0.75）。

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

Answer 5

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

假设您需要在哈希表中存储75个值，并且您有100个空数组块来存储它们，这里碰撞的几率最小化，加载因子为0.75。

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

现在其他方式你有75个条目和1000个空数组块（加载因子0.075），这将导致很多空块，这是一个很大的空间浪费。

因此，拇指规则是随着负载系数的增加，您的搜索时间将增加，并且当它接近0时，会浪费更多的存储空间。

因此，这是一个时空交易。