Algorithm 与条目计数相关的哈希表应该初始化多大？

是否存在与条目计数相关的哈希表的最佳大小

因此，对于条目=

n

是否有一个最佳（或推荐）大小

s

用于哈希表，它取决于

n

？比如说

2n

（条目计数加倍）或其他值

---

是否取决于内部结构（哈希函数、桶大小等）？请在声明某些内容时提供一些证据。

表的大小与条目数之间的比率称为哈希表的大小

负载系数决定了预期的运行时行为。要应用通常的界限（即所有操作的预期时间O（1）），它必须小于1

---

在实践中，皮特·威尔逊（Pete Wilson）的评论适用于：为了不浪费空间，我们尝试将负载系数保持在接近1的水平；表的素数大小通常用于改善哈希函数的冲突特性，但也存在其他策略。

在java中，对于类HashTable，默认的加载因子（.75）在时间和空间成本之间提供了良好的折衷

较高的“载荷系数”值会降低空间需求并增加碰撞的几率。冲突会增加执行get（）和put（…）所需的时间

较低的负载系数值会增加磁盘/内存空间需求，导致大量的保留空间永久未使用。箱子数量的增加降低了碰撞的几率

因此，加载因子（.75）意味着哈希表存储箱已满75%。如果要存储75个元素，则哈希表中的容器数应为100

因此，在回答您的问题时，假设N是要存储在哈希表中的项数，则哈希表的大小应为（1.33*N）。在某些情况下，其他情况可能会使不同的负载系数更快

---

我（几年前）被教导s的大小至少应该是大于n的下一个素数。这里有一个很好的讨论，所以选择

1.5n

的大小通常是可以的，如果我不期望它增长的话。这个答案是正确的，但我觉得有点令人沮丧。负载系数描述条目与可用存储桶的比率。当然“一个人试图”将负载因子保持在1附近，因为这是散列的全部目的——因此，对于初始问题，没有任何信息告诉我们。据我所知，“最佳大小”取决于所需内存量与冲突发生频率之间的关系。使用更多内存可以减少冲突，但可能会浪费空间。因此问题是：平均而言，使用上下文可能有多少个条目，以及（哈希方法预期的特定类型的）该数量的条目可能有多少个冲突？@Asher完全正确。但是，在性能关键型应用程序中，您通常非常清楚需要多少条目。