算法分析 - O(1) 中的哈希搜索与冲突列表

Question

我正在阅读一本教科书，它正在谈论哈希列表的实现。关于哈希表，教科书上说：

如果元素在数组位置之间均匀分布，则链接方法工作得相当好，这种情况称为统一散列。例如，如果我们有 300 名员工和 100 的数组大小，并且如果每个职位大约有 3 名员工，给予或接受一名员工，那么我们仍然有一个在 O(1) 时间内运行的搜索函数，因为没有更多需要进行 3 或 4 次比较才能找到合适的员工。

这是假设我们有一个包含 100 个元素的数组（用于哈希表），每个元素都是一个链表，用作该元素的冲突列表。

所以，我的问题是：

本段指出，给定我们的散列算法，我们可以在 O(1) 时间内搜索一个元素。不过这让我很吃惊，因为你的数据集越大，你的碰撞就越多，你的碰撞列表也会越大。因此，冲突列表会随着 (n = # 个员工) 缓慢增长，但它们会增长。

我原以为这会使算法在 O(n) 时间内起作用。

是否根据散列函数和预期的数据集大小对散列表进行不同的分析？大多数算法分析似乎不包括指定的数据集大小，因此在这种情况下，哈希表分析包括 (n) 的有限大小，这让我感到惊讶和困惑。

Answer 1

这里没有直接提到的重要细节是，如果哈希表的负载因子超过某个阈值，假设哈希表会自行调整大小。

乍一看你的想法是正确的，但他们假设负载因子将被允许无限增长（这样碰撞列表会慢慢变长而没有任何上限）。

如果调整哈希表的大小以将负载因子保持在常数 L 以下，则根据定义，在搜索冲突列表时最多会有 L 个操作。由于 L 与 N（表中的项目数）无关，因此搜索仍然是常数时间。

Answer 2

在一个典型的实现中，在哈希表的负载超过某个界限后（当前 Java 实现使用 0.75），该表会动态调整自身大小。

这确保有“足够”的键来实现 O(1) 的平均性能。

Answer 3

工作单元是一个元素。在 M 个插槽中的 N 个项目的哈希表中查找一个元素是一个 O(1) 过程。

创建哈希表当然（至少）是一个 O(N) 过程。查找所有元素也是（至少）一个 O(N) 过程。

二分查找或树的逻辑相同：O(some_function_of_N) 是查找 one 元素所需的工作量（给定一个大小为 N 的数组或树）。