在Java中检查并在网上搜索散列表的代码示例，似乎调整表格大小是通过加倍来完成的。
但大多数教科书都说最好的表格大小是质数。
所以我的问题是：
加倍的方法是因为：
n+=2 找到下一个质数，并使用模运算测试素性的时间复杂度是O(loglogN)，这很便宜），或者更新：
教科书中提出的使用质数的方式是必须的，以确保某些属性可以工作（例如，二次探测需要一个质数大小的表来证明例如如果表不满项X将被插入）。
发布的重复链接通常询问增加任何百分比，例如25％或下一个质数，所接受的答案说明我们加倍是为了使调整大小操作“罕见”，以便我们可以保证平摊时间。
这并没有回答拥有质数大小的表格大小，并使用比加倍更大的质数进行调整大小的问题。 因此，想要保留质数大小的属性，同时考虑调整大小开销。
就素数大小而言，这取决于您选择的冲突解决算法。有些算法需要素数表大小（双重散列，二次探测），而其他算法则不需要，并且它们可以从2的幂表大小中获益，因为它允许非常便宜的模运算。然而，当最接近的“可用表大小”相差2倍时，哈希表的内存使用可能是不可靠的。因此，即使使用线性散列或分离链接，您也可以选择非2的幂大小。在这种情况下，反过来，值得选择特定的素数大小，因为：问：但是大多数教科书都说表格的最佳大小是质数。
Q: 说实话，我有点迷糊你是否推荐使用素数。似乎这取决于哈希表的变体和哈希函数的质量？
哈希函数的质量并不重要，您总是可以通过 MurMur3 平衡来“改进”哈希函数，这比从2的幂转换为素数表大小更便宜，详见上文。
我建议选择素数大小，使用 QHash 或者二次探测算法（不是同一个），仅当您需要精确控制哈希表负载因子以及可预测的高实际负载时。使用2的幂作为哈希表大小，最小调整因子为2，通常我们不能保证哈希表的实际负载因子会高于0.5。请参阅此答案。
否则，我建议使用2的幂大小的哈希表和线性探测。
问：为什么会选择扩容策略是倍增？
是因为它易于实现，还是
基本上，在很多情况下是这样的。 请看关于负载因子的详细回答:
负载因子不是哈希表数据结构的必要部分——它是定义动态系统行为规则的方式（扩容/缩容哈希表是一种动态系统）。
此外，在我看来，在95%的现代哈希表案例中，这种方式过于简化，动态系统表现不佳。
什么是倍增？它只是最简单的调整大小策略。这个策略可以是任意复杂的，以最优的方式执行您的用例。它可以考虑当前哈希表大小、增长强度（自上次调整大小以来进行了多少次get操作）等因素。没有人禁止您实现这样的自定义调整大小逻辑。
有一个好的做法是预先计算一些素数哈希表大小的子集，以便在运行时使用二分查找来选择它们之间的大小。请参见双哈希容量列表和解释，QHash容量。或者，甚至可以使用直接查找，这非常快速。问：查找质数太低效了吗（但我认为通过n+=2寻找下一个质数并使用模运算测试素性是O(loglogN)，这是便宜的）
问：或者这是我的误解，只有某些哈希表变体需要素数表大小？
是的，只有某些类型需要，详见上文。
java.util.HashMap) 在一个链表（或[自JDK8起]树，取决于桶的大小和溢出）中链接桶碰撞。java.util.HashMap将小桶以插入的相反顺序排序，然后将它们分成两个服从该顺序的子结构。它通过哈希码将大桶保持在二叉树中并类似地分割该树以保留该顺序。
NB:这些技巧直到JDK8才被实现。Java.util.HashMap只会增加大小（永远不会减小）。但是将哈希表减半与将其加倍相似。Object实现者确保哈希码的低位是分布良好的。完全有效的哈希码总体上可能分布良好，但在其低位上分布不良。因此，遵守hashCode()的一般契约的对象在实际使用中可能仍然失败！Java.util.HashMap通过对提供的hashCode()实现应用额外的哈希“扩散”来减轻这种情况。那个“扩散”非常快粗糙（xors高16位和低位）。Java.util.HashMap 没有这样做。你是否注意到服务器受益于定期重新启动？不卸载类和内部“缓冲区”大小不会缩小等问题会导致系统不泄漏却不必要地持有空闲资源。 - Persixty