带整数键的哈希表（字典等）
我已经困惑了几天……随意拍下我的任何假设。
我们正在使用带整数键的字典。 我假设在这种情况下密钥的值直接用作哈希。 这是否意味着（如果密钥分组在一个小范围内）密钥散列的分布（与密钥本身相同，对吗？）将处于类似的小范围内，因此哈希表的选择不好？
是否更好的是提供一个IEqualityComparer，它使用素数和模数学来做一些聪明的东西来计算更好的分布式哈希？
它并没有直接使用，因为字典仍然会向键询问其哈希值 – 但Int32的哈希值只是值，所以你的问题的主旨是相关的，是的。
我相信.NET字典的工作方式不依赖于均匀分布的哈希值。 它需要hash % bucketCount ，其中bucketCount始终为prime。 （那是从记忆中来的 – 我可能是错的。）
如果它们碰巧被铲斗数量隔开，你当然仍然会得到一组低效的密钥。 但情况总是如此 – 如果哈希表具有唯一的哈希值并且表为每个可能的哈希维护了一组桶，那么对于所有键，哈希表只能真正地为 O（1）:)实际上它往往不是一个问题。 如果您碰巧知道这将是一个问题，那么是的，自定义IEqualityComparer可能有所帮助。
假设您正在使用标准库哈希表实现，那么即使键是整数，关键也不是哈希，完全是您指出的原因。
因此，虽然关于哈希分布的逻辑是正确的，但您最初假设整数键意味着哈希=键可能不是。
如果我错了：.NET那么哦; 这更像是一个普遍的答案。 🙂
在做一些聪明的事情之前，我会按原样测试它的速度，看看它是否适合你。 如果不是，那就试试聪明的事情吧。 但我希望最好不要管它; 更重要的是，哈希不会发生碰撞，只要发生这种情况，生活就会好起来。