哈希表桶实现答案

【问题标题】：Hashtable bucket implementation哈希表桶实现
【发布时间】：2016-06-30 07:06:28
【问题描述】：

在我见过的每个哈希表实现中，哈希用于选择一个“桶”，它是一个项目列表，然后遍历该列表，直到找到我们想要的项目。

我的问题是为什么它总是一个列表？据我所知，向量几乎总是更有效，那么为什么不使用向量作为存储桶呢？列表是否有某些特性使其非常适合用作哈希表中的存储桶？

我在这里使用 C++ 术语来表示矢量，但它确实适用于任何语言。

【问题讨论】：

【解决方案1】：

哈希表用于关注速度的地方。

与std::list 相比，std::vector 中添加或删除元素要慢得多，std::list 是作为双向链表实现的。

当向std::vector 添加一个元素时，如果向量大小超过向量容量，所有元素都必须移动到内存中。在std::list 中，只分配了新元素的内存，并且必须调整最后一个元素的下一个指针。

当从std::vector 中删除一个元素时，所有后续元素都必须移动到内存中。在std::list 中只需要调整 prev 和 next 指针。

可能是另一个原因：如果使用 std::list 元素将永远不会在内存中移动，并且一旦将元素添加到地图中，您就可以使用裸指针来寻址这些元素。使用 std::vector 时，如果调整了向量的大小，则会移动元素并且所有裸指针都将悬空

OOT：另一种解决方案是根本不使用存储桶列表：如果新元素将散列到位置 7 并且该位置已被占用，则新元素将被写入位置 8（依此类推） .如果哈希表几乎为空，则此解决方案非常快，如果表几乎已满，则此解决方案很慢。如果元素的数量超过哈希表的大小，则必须对其进行调整大小和重组，这是一项非常昂贵的操作。

【讨论】：

附加到一个向量被摊销 O (1)，所以插入到哈希表也应该是。删除，我同意，但检索元素会快得多，因为对向量的迭代要快得多。我仍然不明白为什么总是选择一个列表。如果你做了很多追加和获取，但没有很多删除怎么办？似乎矢量在那里更快......
将元素附加到向量的复杂度是O(1)，但仍然是一个非常昂贵的操作，大小超过容量。
所以它不是为了实时应用，而是为了高吞吐量，你只关心摊销
也许还有另一个原因：如果使用 std::list 元素将永远不会在内存中移动，您可以使用裸指针来寻址元素。使用 std::vector 时，如果调整了向量的大小，则元素将被移动，并且所有裸指针都将悬空。
哦，真的，没想到...将其添加到您的答案中，我会投票