实际上，根据我的计算，“完美”的负载系数更接近于log 2(~ 0.7)。尽管任何负载系数小于这个值都会产生更好的性能。我觉得点75手枪可能是从帽子里拿出来的。

证明:

可以避免连锁，并通过预测分支预测 桶是否为空。一个桶可能是空的，如果它的概率 空的超过。5。

s表示键的大小，n表示添加的键的数量。使用二项式 定理，一个桶为空的概率为:

P(0) = C(n, 0) * (1/s)^0 * (1 - 1/s)^(n - 0)

因此，如果小于，则桶可能是空的

log(2)/log(s/(s - 1)) keys

当s达到无穷大时，如果添加的键数等于 P(0) = .5，则n/s迅速逼近log(2):

lim (log(2)/log(s/(s - 1)))/s as s -> infinity = log(2) ~ 0.693...

从文档中可以看到:

负载因子衡量的是在哈希表的容量自动增加之前允许达到的满度

这实际上取决于您的特定需求，没有“经验法则”来指定初始负载系数。

HashMap的默认初始容量为16，负载因子为0.75f(即当前映射大小的75%)。负载因子表示HashMap容量应该在哪个级别加倍。

例如，容量与负载系数的乘积为16 * 0.75 = 12。这表示在HashMap中存储了第12个键值对后，其容量变为32。

对于HashMap, DEFAULT_INITIAL_CAPACITY = 16, DEFAULT_LOAD_FACTOR = 0.75f 这意味着HashMap中所有条目的最大数量= 16 * 0.75 = 12。当第13个元素被添加时，HashMap的容量(数组大小)将翻倍! 完美的例子回答了这个问题: 图片从这里拍摄:

https://javabypatel.blogspot.com/2015/10/what-is-load-factor-and-rehashing-in-hashmap.html

实际上，根据我的计算，“完美”的负载系数更接近于log 2(~ 0.7)。尽管任何负载系数小于这个值都会产生更好的性能。我觉得点75手枪可能是从帽子里拿出来的。

证明:

可以避免连锁，并通过预测分支预测 桶是否为空。一个桶可能是空的，如果它的概率 空的超过。5。

s表示键的大小，n表示添加的键的数量。使用二项式 定理，一个桶为空的概率为:

P(0) = C(n, 0) * (1/s)^0 * (1 - 1/s)^(n - 0)

因此，如果小于，则桶可能是空的

log(2)/log(s/(s - 1)) keys

当s达到无穷大时，如果添加的键数等于 P(0) = .5，则n/s迅速逼近log(2):

lim (log(2)/log(s/(s - 1)))/s as s -> infinity = log(2) ~ 0.693...

我会选择n * 1.5或n + (n >> 1)的表大小，这将给出不除法的负载因子。66666~，这在大多数系统上是很慢的，特别是在硬件中没有除法的便携式系统上。