是否有任何实现可以在通用散列中选择几个散列函数并尝试使用这些函数将总冲突减少到可接受的水平并以最小的冲突返回最佳结果？
如果存在，从现有数组构建哈希表比首先创建哈希表更可靠，那么插入所有元素，不是吗？
以下段落来自算法简介。
“如果恶意攻击者选择通过某些固定哈希函数进行哈希处理的密钥，那么攻击者可以选择所有哈希到同一个槽的n个密钥，产生的平均检索时间为.n /。任何固定的哈希函数容易受到这种可怕的最坏情况行为的影响;改善这种情况的唯一有效方法是以一种独立于实际存储的密钥的方式随机选择散列函数。这种方法称为通用散列，可以无论对手选择哪种钥匙，平均产量都会表现出良好的表现。
在通用散列中，在执行开始时我们选择散列函数 从精心设计的功能类中随机选择。与快速排序的情况一样，随机化保证没有单个输入总是会引起最坏情况的行为。因为我们随机选择散列函数，所以算法在每次执行时都会表现不同，即使对于相同的输入也是如此，保证良好 任何输入的平均情况表现。回到编译器的例子 在符号表中，我们发现程序员选择的标识符现在不能导致一致的散列性能差。仅当编译器选择导致标识符集散列不良的随机散列函数时才会出现性能不佳，但这种情况发生的概率很小，并且对于任何相同大小的标识符集都是相同的。“
答案 0 :(得分：3)
如果您事先知道密钥，则可以使用perfect hashing来避免任何冲突。所以，如果你在某个地方拥有所有元素（如在你的例子中，在数组中），并且不会有新的插入，那么你可以做得更好。
事实上，在真正的应用程序中，键通常来来去去。表格不断变化。我不了解实现，但一如既往地归结为权衡。您正在尝试为快速查找交换额外的安全性，并且您将支付额外的代码复杂性和减速以及可能代价高昂的插入，这将在有大量冲突时重新创建哈希。但你真的需要那种安全吗？如果你有很多碰撞，为什么不简单地增加表的大小？
将总碰撞减少到可接受的水平
很多冲突的可能性非常小（具有良好的实现方式，使表不会密集），并且您已经针对恶意输入进行了防御（因为攻击者不知道如何滥用密钥）。对于现实生活中的应用，这已经比“可接受的水平”更好了。