哈希表链表中项目的删除时间

Question

我目前正在阅读 CLRS 书籍并查看其中如何定义哈希表，在谈到开放哈希和使用链接解决冲突时，有一段文字如下：

If the hash table supports deletion, then its linked lists should be doubly linked
so that we can delete an item quickly. If the lists were only singly linked, then to
delete element x, we would first have to find x in the list T[h(x.key)] so that we
could update the next attribute of x’s predecessor. With singly linked lists, both
deletion and searching would have the same asymptotic running times.)

我不明白为什么会出现这种情况（或者更具体地说是如何），这不是一个问题，即当你知道元素加倍时为什么从链表中删除它会更快链表，我想我应该说清楚...

这与实际知道位置的方式有关，因此双向链表可以产生这种差异，因为查看哈希删除伪代码（如下），密钥用于生成导致正确的哈希可以找到链表的数组索引，但如何准确地将其转换为项目链表中的实际位置？

CHAINED-HASH-DELETE(T, x)
1 delete x from the list T[h(x.key)]

在我看来，仅对链接列表的键进行哈希处理，因此在任何一种情况下，仍需要搜索列表以找到当前正在删除的实际值？

我确定有一个简单的答案，但我不清楚！

Answer 1

在我看来，仅对链接列表的键进行哈希处理，因此在任何一种情况下，仍需要搜索列表以找到当前正在删除的实际值？

没错，当有人询问erase(key) 时，双向链表没有任何好处，因为即使遍历单链表也很容易擦除。

不过，像（伪代码）这样​​的代码还是很常见的......

if (iterator i = hash_table.find(key)) {
    do_something_with(*i);
    if (should_erase(*i))
        erase(i);
}

这里，迭代器i可以是一个指向双向链表中一个节点的指针，因此每个解引用操作*i访问与该节点关联的元素/值都不必重复任何部分哈希表桶查找或双向链表搜索。

如果它随后决定erase(i)，则迭代器无需再次搜索即可识别要擦除的节点。

如果你只使用单链表，那么erase(iterator) 为了避免重新搜索，它需要存储一个指向前一个元素的下一个指针的指针（这实际上是 GCC 的 C++ 哈希表容器所做的）。如果它只存储它（以保持迭代器更小），那么要访问迭代器逻辑寻址的元素，它必须首先查找前一个元素的下一个指针，然后跟随它到逻辑寻址的节点：这不是超级有效的。如果它存储了逻辑寻址元素的地址和前一个元素（或者更具体地说是它的下一个指针），那么迭代器就会变成更大的对象，也会对内存使用和性能产生潜在影响。尽管如此，您还是为列表中的每个链接保存了一个“上一个”指针，而且可能有很多元素而不是很多迭代器。