负载因子对查找时间的影响？答案

【问题标题】：Impact of load factor on lookup time?负载因子对查找时间的影响？
【发布时间】：2018-02-18 18:43:17
【问题描述】：

作为一般规则，默认负载系数 (.75) 在时间和空间成本之间提供了良好的折衷。较高的值会减少空间开销，但会增加查找成本（反映在 HashMap 类的大多数操作中，包括 get 和 put）。

我不知道如何将负载因子增加到 1，增加查找时间

例如：- 初始容量为 16，负载因子为 1，然后在大小达到 16 * 1 = 16 后调整到 32。现在，如果我输入任何新条目，查找时间将如何如果负载因子为 0.75（在这种情况下，hashmap 的大小将调整为 2）

正如这个答案所说What is the significance of load factor in HashMap?，空闲桶的数量越少，碰撞的可能性。

我不确定空闲桶的数量与碰撞几率的关系。

据我了解，桶是根据关键对象的哈希码决定的。如果它与桶中的一些已经关键的对象相同，那么只有碰撞的机会，否则它将进入不同的桶（不在可用的桶中）。那么为什么碰撞与免费存储桶有关？您的意思是说，即使 hashcode 不同并且 hashmap 已满，它也会尝试将其放入现有存储桶中？

它不与What is the significance of load factor in HashMap? 重复。我在问那个链接中没有回答的具体点

【问题讨论】：

标签： java hashmap

【解决方案1】：

那么为什么碰撞与空闲桶有关？你的意思是说，即使hashcode不同，hashmap满了，也会尽量适应现有的bucket？

密钥的哈希码可以是从 0 到 2³¹-1 的任何 int 值。这意味着hashCode()方法的值通常大于桶的数量。因此，两个不同hash码的key可能会映射到同一个bucket。

例如，如果桶数为 16，则哈希码 1、17、33、49 等...都会映射到 #1 桶。

如果桶数较多，则可以将较少数量的唯一哈希码映射到同一个桶中，因此同一个桶持有多个条目的可能性较小。

例如，如果桶数增加到 32，现在哈希码 1 和 33 仍将映射到桶 #1，但哈希码 17、49 等...将映射到不同的桶（ #17) - 因此碰撞的可能性较小。

当负载因子 hashCode 实现，它返回的唯一值很少）。

【讨论】：

【解决方案2】：

哈希表由数组支持。
后备数组的大小和数据结构哈希表的大小不是同一个数字。
由于冲突，一个元素最终可能与另一个元素完全相同，并且冲突的数量也取决于支持数组的大小（除了哈希函数），因为它是
index_in_array = Math.abs(element.hashCode() % array.length);
如果您需要为大量元素使用非常小的后备表，即使是完美的哈希函数也无济于事。
后备数组越大，放置元素的空间就越大，发生冲突的可能性就越小。
负载因子（插入的元素与数组大小的比率）决定了后备数组何时应该变大。
对于 1 的加载率，这意味着您已经用尽了后备数组的所有插槽，这意味着您遇到了更多的冲突，因为不可能有每个插槽有 1 个元素的情况。
如果您遇到这种情况，您应该首先使用普通数组

【讨论】：