java – 哈希桶的数量

发布时间：2020-12-14 05:52:14 所属栏目：Java 来源：网络整理

导读：在 HashMap文档中,提到：初始容量只是创建哈希表时的容量 capacity是哈希表中的桶数. 现在假设我们的初始容量为16(默认值),如果我们继续添加100个元素,则hashmap的容量为100 * loadfactor. 散列桶的数量是100还是16？编辑：从我读到的解决方案：桶不仅仅

在 HashMap文档中,提到：

>初始容量只是创建哈希表时的容量
> capacity是哈希表中的桶数.

现在假设我们的初始容量为16(默认值),如果我们继续添加100个元素,则hashmap的容量为100 * loadfactor.

散列桶的数量是100还是16？

编辑：
从我读到的解决方案：桶不仅仅是添加的元素.
以此为观点：因此,如果我们将字符串添加为键,我们将获得一个元素/存储桶,从而导致大量空间消耗/复杂性,我的理解是正确的吗？

解决方法

既不是100也不是16桶.最有可能会有256个存储桶,但文档无法保证这一点.

从updated documentation link：

The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity,the hash table is rehashed (that is,internal data structures are rebuilt) so that the hash table has approximately twice the number of buckets.

(强调我的)

因此,如果我们忽略上面的“大约”一词,我们确定每当哈希表变为75％满(或者在构造函数中指定的任何加载因子)时,哈希桶的数量加倍.这意味着每当插入第12,24,48和96个元素时,桶的数量就会翻倍,总共会有256个桶.

但是,正如我在文档片段中强调的那样,这个数字大约是之前大小的两倍,所以它可能不是256.事实上,如果倒数第二次加倍被稍微大一点的加倍所取代,那么最后的加倍可能是永远不会发生,所以最终的哈希表可能只有134个桶,或者可能大于256个元素.

注：我到达了134号,因为它是最小的整数N,使得0.75 * N> 0. 100.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!