负载系数对查找时间的影响？

Question

As Java doc explains

  

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

我没有得到如何将负载因子增加到1，增加查找时间

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

，则更多

正如这个答案所说 What is the significance of load factor in HashMap?，免费存储桶的数量越少，越高 碰撞的机会。

我不确定免费存储桶的数量与碰撞几率有关。

根据我的理解，桶是基于密钥对象的哈希码决定的。如果它与桶中已经存在的关键对象相同，则只有碰撞的可能性，否则它将变为不同的桶（在可用桶之外）。那么碰撞怎么会与免费桶相关呢？你的意思是说即使hashcode不同而hashmap已经满了，那么它会尝试将它放在现有的存储桶中吗？

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

Answer 1

  

那么为什么碰撞与免费桶有关呢？你的意思是说即使hashcode不同而hashmap已满，那么它会尝试将它放在现有的存储桶中吗？

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

例如，如果桶数为16，则哈希码1,17,33,49等将全部映射到桶＃1。

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

例如，如果桶的数量增加到32，则现在哈希码1和1。 33仍将映射到存储桶＃1，但是哈希码17,19等将被映射到不同的存储桶（＃17） - 因此冲突的可能性更小。

当负载系数<1时如图1所示，每个桶中的平均条目数是＆lt; 1，这为您提供了持续查找时间的好机会（除非您的密钥具有可靠的hashCode实现，返回很少的唯一值）。

Answer 2

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