关于GetHashCode实现的问题

时间:2009-02-05 15:16:52

标签: .net performance clr

http://msdn.microsoft.com/en-us/library/system.object.gethashcode(VS.80).aspx说:

  

为获得最佳性能,哈希函数必须为所有输入生成随机分布。

它对性能有任何影响,或者可以使用不提供“随机分布”但不会引起更多冲突的函数(如返回this.Id)吗?

5 个答案:

答案 0 :(得分:3)

return this.Id通常没问题(特别是如果Id是不可变且唯一的) - 主要思想是避免碰撞。但是,请考虑未决数据 - 您尚未保存的27行中的Id是什么?

另请注意GetHashCodeEquals实施must agree

答案 1 :(得分:1)

使用this.Id通常没问题。基础是您不希望太多的冲突最终会出现在同一个存储桶中。桶号通常是通过获取哈希码并将其视为“mod x”获得的,其中x是哈希表中的桶数,通常是素数(或可能的素数)。

如果您只是使用增加的ID(1,2,3,4 ...),那么就桶分布而言,这将最终变得非常随机。只有当您的ID遵循的模式可能会为您需要担心的大量条目提供相同的桶号。

答案 2 :(得分:0)

似乎措辞不好......我认为他们的意思是哈希码应该“均匀分布”在所有可能的int值上(.net专家请纠正我,如果我错了),这将有助于减少碰撞。

这是一个例子:假设我的所有哈希码都在1到10的范围内。如果我使用哈希码来计算数组长度为100的数组索引,那么我最多只能得到10个不同的索引。这意味着我的阵列利用率很低,我会遇到很多冲突。

答案 3 :(得分:0)

它可能对例如有影响。根据高位(不常见)散列到桶中的散列表。此外,如果您的ID例如都可被4整除,则可能会使哈希到存储桶hash_code%buckets中的哈希表仅使用每四个桶。

答案 4 :(得分:0)

我更喜欢使用

this.Id.GetHashCode();

我认为这使得散列更有可能被正确分发,而不是直接使用Id。