爲什麼會loadfactor 0.75

我從javadoc的時候有太多的衝突閱讀本爲ConcurrentHashMap 爲什麼會loadfactor 0.75

該表是動態擴展（即，具有不同的散列碼，但落入同樣的鍵槽模表的大小），每個映射保持大約兩個倉的預期平均效果（對應於調整大小的0.75個負載因子閾值）。

如果是每個映射（key-> value）的兩個bin，那麼負載因子是不是0.5，而不是0.75？

2014-09-30 Qiang Li

FWIW，描述寫得很差 - 當存儲元素的數量大於0.75時間槽/桶的數量時，「調整大小的負載因子閾值爲0.75」意味着「表格是動態擴展的」與「當碰撞太多時」有微妙差別 - 你可能仍然有0次碰撞，或者每個現有元素可能發生碰撞。 – 2014-10-03 08:16:55

此外，「碰撞」（即，具有不同散列碼但落入與表格大小相同的時隙中的鍵）「 - 碰撞是散列碼是否相同的衝突......該區別對於調整大小是否可以消除碰撞。 – 2014-10-03 08:19:38

拆分在Map的整個運行時間內分攤的分箱的成本非常低。目標閾值（調整後）是 0.5。但是，分割倉的觸發閾值爲0.75（可能是因爲0.75是0.5+（0.5/2），大50％）。所需的垃圾箱數量取決於碰撞次數和算法的效率，但假設碰撞很少發生（因爲hashCode()的密鑰分配很好）。

2014-09-30 04:55:19

正確的觀點，但你的「目標閾值（調整後）是0.5」。與「預期*平均*每個映射保持大約兩個分箱的效果」相沖突，這意味着需要0.5以上的平均後調整負載大大減少* 0.5。 – 2014-10-03 08:06:32

回答