【问题标题】:why would loadfactor be 0.75为什么负载因子会是 0.75
【发布时间】:2014-09-30 04:46:02
【问题描述】:

我正在从 ConcurrentHashMap 的 javadoc 中阅读此内容

当发生太多冲突时(即,具有不同哈希码但以表大小为模的键落入同一槽中)时,表会动态扩展,每个映射保持大约两个 bin 的预期平均效果(对应于调整大小的 0.75 负载因子阈值)。

如果每个映射(key->value)是两个 bin,那么负载因子不会是 0.5,而不是 0.75?

【问题讨论】:

  • FWIW,描述写得很糟糕-当存储元素的数量> 0.75乘以槽数/时,“调整大小的负载因子阈值为0.75”意味着“表格动态扩展” buckets,这实际上与“当有太多碰撞时”略有不同 - 你可能仍然有 0 个碰撞,或者每个现有元素都可能发生碰撞。
  • 进一步,关于“冲突(即,具有不同哈希码但落入以表大小为模的相同槽中的键)” - 无论哈希码是否相同,冲突都是一种冲突。 ..这种区别对于调整大小是否可以消除冲突是有意义的。

标签: java hash hashmap


【解决方案1】:

拆分箱的成本不低,该成本在Map 的整个运行时中摊销。目标阈值(调整大小后) 0.5。但是,拆分箱的触发阈值是 0.75(大概是因为 0.75 是 0.5+(0.5/2),大 50%)。所需的 bin 数量取决于冲突的数量和hashCode() 算法的效率,但假设冲突很少见(因为hashCode() 很好地分配了密钥)。

【讨论】:

  • 正确的视角,但您的“目标阈值(调整大小后)为 0.5。”与“每个映射维持大约两个 bin 的预期 平均 效果”相冲突,这意味着 0.5 最终需要一个远小于 0.5 的调整后负载.
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-04-21
  • 2016-12-21
  • 2019-05-02
  • 2012-08-20
  • 1970-01-01
  • 2013-07-28
相关资源
最近更新 更多