哈希表桶数组答案

【问题标题】：Hash Table Bucket Array哈希表桶数组
【发布时间】：2011-08-22 08:39:45
【问题描述】：

如果我有 50,000 个条目并且说，哈希表中有 100,000 个可用插槽。如果不使用 LinkedLists 以使数组永远不会“溢出”，那么为每个索引选择合适的存储桶数组大小的最佳方法是什么？过量 30% 合适吗？

【问题讨论】：

【解决方案1】：

某些语言支持数组的动态大小（无需声明数组的大小）。数据动态决定数组的大小，需要这个大小的语言也支持动态数组。

【讨论】：

我不确定你从哪里得到“大部分”。当然，在我使用的语言（Java、C#、C、C++）中，数组在创建后大小是固定的。当一种语言支持“动态调整大小”时，通常会涉及到复制——所以仍然值得一开始就尝试获得合适的大小。
在 obj-c 中，数组是动态的，我也使用 java、c#、c 和 c++，但没有使用动态数组概念，但我想我在大学阶段读过 c 和 c++。目前我在 obj-c 工作，这就是为什么我给出了这种类型的答案。我已经从你的书中读过 C#，所以我不能说其他任何东西。所以我将删除大部分单词。
谢谢您，先生，这对我来说是一个很好的答案（如果您这么说，相当于给我 +10 票）。

【解决方案2】：

如果您为存储桶使用固定大小的数组，那么没有小于 50,000 的存储桶大小可以保证永远不会溢出，除非您有关于 50,000 中的键分布的其他信息（即，如果您知道它们是整数 1 .. 50,000 那么这将是微不足道的）。

但通常你不想依赖大桶，因为这是 O(n) 来搜索桶。相反，使用可变大小的表和可变大小的存储桶是一个更好的主意。存储桶可以简单地是数组，每次它们被填满时，它们的大小都会增加一倍。类似地，每次达到 90% 满时，哈希表的大小都会增加一倍。这是一种标准类型的方法。

正如之前的海报所提到的，大多数列表的实现，无论是数组还是链表，都会在列表满时自动为您重新分配存储空间。

【讨论】：

【解决方案3】：

如果您知道密钥先验，则可以计算出minimal perfect hash。因此，如果您知道键并且可以定制散列函数，则存储桶大小为 1 就足够了。

如果您事先不知道密钥——或者知道密钥，但不能改变哈希函数——那么攻击者就有可能选择最坏情况的密钥集（即所有哈希到同一个桶）。为了保证桶没有溢出，您需要一个等于桶数的桶大小。如果您愿意容忍溢出的可能性，则可以进行更复杂的分析以选择涵盖大部分情况的存储桶大小。

【讨论】：