与条目数相关的哈希表应该初始化多大？
与条目计数相关的哈希表是否存在最佳大小？
那么，对于 Entry = n ，哈希表是否存在取决于 n 的最佳（或推荐）大小 s ？可以说 2n （条目数加倍）或其他值？
是否取决于内部结构（哈希函数、桶大小等）？索赔时请提供一些证据。
Is there an optimal size for a hashtable related to the entry count?
So for entries = n is there an optimal (or recommended) size s for the hashtable which depends on n? Lets say 2n (double the entries count) or some other value?
Is it depending on the internal structure (hash function, bucket size, etc.)? Please provide some evidence when claiming something.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
表的大小与条目数之间的比率称为负载因子< /a> 哈希表。
负载因子至关重要地决定了预期的运行时行为。为了应用通常的界限（即所有操作的预期时间 O(1)），它必须小于 1。
在实践中，Pete Wilson 的评论适用：人们试图将负载因子保持接近 1，以免浪费空间；表的素数大小通常用于改善哈希函数的冲突特性 - 但也存在其他策略。
The ratio between the size of the table and the number of entries is called the load factor of a hash table.
The load factor crucially determines the expected runtime behaviour. For the usual bounds (i.e. expected time O(1) on all operations) to apply, it has to be smaller than 1.
In practice, the remark by Pete Wilson applies: one tries to keep the load factor close to 1 in order not to waste space; a prime number size for the table is often used to improve the collision characteristics of the hash function – but other strategies exist.
在 java 中，对于 HashTable 类，默认负载因子 (0.75) 在时间和空间成本之间提供了良好的权衡。
较高的负载系数值会降低空间需求并增加碰撞的可能性。冲突会增加执行 get() 和 put(...) 所需的时间。
较低的负载因子值会增加磁盘/内存空间需求，导致大量保留空间永久未使用。垃圾箱数量的增加降低了碰撞的可能性。
因此，负载系数为 (0.75) 意味着哈希表 bin 已满 75%。如果要存储 75 个元素，则 HashTable 中的 bin 数量应为 100。
因此，回答您的问题，假设 HashTable 中要存储的项目数为 N，则 HashTable 的大小应约为 (1.33 * n ）。在某些情况下，其他情况可能会使不同的负载因子更快。
http://docs.oracle.com/javase /1.4.2/docs/api/java/util/Hashtable.html
In java, with class HashTable, the default load factor (.75) offers a good tradeoff between time and space costs.
A higher load factor value decreases the space requirements and increases the odds of a collision. A collision increases the amount of time needed to perform a get() and put(...).
A lower load factor value increases disk/memory space requirements, causing lots of reserved space that is permanently unused. The increased number of bins decreases the odds of a collision.
So a load factor of (.75) means the HashTable bins are 75% full. If you have 75 elements to store, the number of bins in your HashTable should be 100.
Therefore, answering your question, given N as the number of items to store in your HashTable, the size of your HashTable should be about (1.33 * n). Other circumstances may make different load factors faster in some situations.
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Hashtable.html