为什么小负载因子哈希表的大 O 复杂度为 O(1)？答案

【问题标题】：Why is the Big-O complexity for Small Load Factor HashTables O(1)?为什么小负载因子哈希表的大 O 复杂度为 O(1)？
【发布时间】：2019-12-24 05:03:54
【问题描述】：

我无法理解使用负载因子对哈希表的链式和开放式寻址进行大 O 分析。

据我了解：

LoadFactor = (HashTable 中的条目数)/(HashTable 中的“槽”数) = (n/m)

因此，LoadFactor 反映了输入到 HashTable 中的数据正在使用多少 HashTable。

对于链式哈希表，最坏情况的时间复杂度为 O(n)，因为所有元素散列到 HashTable 中的最后一个槽的数据分布不均匀，将问题减少到在大小为的链表中进行搜索n.

对于开放地址哈希表，最坏情况时间复杂度为 O(n)，因为再一次，所有元素散列到一个 hashCode 的数据的非均匀分布将导致所有元素连续输入。因此，问题简化为在大小为 n 的数组中进行搜索。

对于最坏的情况，我假设 n>m。

现在对于较小的负载因子，链式哈希表和开放地址哈希表都会产生 O(1)。

我看不出 n>m 和 n 之间的区别

为什么会这样？

【问题讨论】：

您似乎混淆了最坏情况复杂性和预期情况复杂性。无论负载因子如何，非自适应哈希表的最坏情况总是 O(n)，因为最坏情况是所有条目都具有相同的哈希值。

标签： data-structures big-o hashtable

【解决方案1】：

小负载因子哈希表的预期时间复杂度为 O(1)，因为访问哈希表中的项目的时间不取决于哈希表中的项目数。

【讨论】：

【解决方案2】：

当n 远小于m（桶的数量）时，很可能每个键都散列到一个唯一的桶中。随着n 的增加，发生冲突（两个键散列到同一个桶）的可能性增加。当n > m，然后由Pigeonhole principle，保证至少有两个key会hash到相同的值。

所以当n 远小于m 时，碰撞的可能性更小，因此预期的查找时间为O(1)。随着项目数量的增加，您需要花费更多时间来解决冲突。

经验证据表明，您不希望负载系数超过 0.75。可能接近 0.70。当n > 0.70*m 时，哈希表变得非常低效。当然，实际数字取决于您的数据，但这是一个很好的经验法则。

Birthday problem 显示当n 接近m 时冲突率如何增加。当您插入表中项目数的平方根时，遇到单个碰撞的可能性接近 50%。如果您要创建一个大小为 365 的哈希表并开始插入项目，那么当您仅插入 25 个项目时，您看到哈希冲突的机会高于 50%。（这是假设一个好的散列函数。一个差的散列函数会增加你发生冲突的可能性。）

【讨论】：