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

时间:2017-09-10 11:26:09

标签: java hashmap

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?不重复。我问的是该链接中没有回答的具体问题

2 个答案:

答案 0 :(得分:2)

  

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

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

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

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

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

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

答案 1 :(得分:1)

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