String 使用salt来避免哈希表冲突怎么样？

如果某个键在哈希表中发生冲突，我希望通过递归地对该键进行盐分来找到另一个位置，直到找到一个空闲位置（始终使用相同的盐分）

例如：

“蜜蜂”和“蚂蚁”散列到7

我在表格中插入“蜜蜂”

然后，当我插入“ant”时，它会发生冲突，我将“ant”与“！23”（结果是“！23ant”）盐析，然后再次调用insert（我存储原始键，但使用盐析键获取索引）

我用这个方法搜索了哈希表，但没有找到任何关于它的资料

---

这种冲突处理方法的缺点是什么？

从性能角度来看，每次哈希冲突都需要您构建一个新字符串，如果输入字符串很长，这可能需要很长时间。还要注意，随着哈希冲突越来越多，构建此字符串的成本也会增加，因此成功查找的代价最终取决于您有多少次冲突

---

将这种基于盐的方法与其他散列方法相比较，我怀疑这种额外的成本会使您的系统在实践中比其他技术（如线性探测或双重散列）更慢，它的分布可能不如您的方法好，但不必做那么多的工作来计算哈希代码和构造辅助字符串。

我看不出这是如何解决任何问题的。让我们玩一玩这样的碰撞：

// Here you would store "bee" and "bug" with the hashes 7 and 8:
"bee" = 7
"bug" = 8

// Here you get a collision and add a "salt":
"bee" = 7
"ant" = 7 -> "!23ant" -> 8

// Depending on the adding order, you can end up with "bug"=8 or with "!23bug=9"
"bee" = 7
"!23ant" = 8
"bug" = 8 -> "!23bug" -> 9

---

那么，您如何知道必须使用“bug”还是“！23bug”进行搜索才能获得哈希值呢。存储此信息将否定快速哈希映射的优势。

您是否使用固定的salt来解决冲突？还是你每次都选一种新的盐？固定盐。在我的示例中，始终是字符串“！23”，如果发生第二次碰撞，您会怎么做？（顺便说一句，您描述的技术与一系列其他哈希策略相关，但我想确保在进入之前了解您的系统。）！23ant=>！23!23ant=>…（我假设一个哈希函数，它为键中的微小更改生成非常不同的哈希）