关于GetHashCode实现的问题

使用这个.id通常是可以的。最重要的是,你不希望发生太多的碰撞,最终结果是相同的。 水桶 . 桶号通常是通过获取散列代码并考虑它“mod x”得到的,其中x是散列表中的桶数,通常是素数(或可能的素数)。

如果您只是使用增加的ID(1、2、3、4…),那么就bucket分布而言,这将是相当随机的。只有当您的ID遵循一个模式时,您才需要担心,这个模式可能会为许多条目提供相同的桶号。

return this.Id 通常会很好(特别是如果 Id 是不变的和独特的)-主要的想法是避免碰撞。但是,还要考虑待处理的数据-什么是 身份证件 在你还没有保存的27行中?

还要注意, GetHashCode 和 Equals 实现方式 must agree .

似乎措词不当…我认为他们的意思是散列码应该“均匀分布” 全部的 可能的 int 价值观(网络专家请纠正我,如果我错了),这将有助于减少碰撞。

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

它可能会对哈希表产生影响,哈希表根据高位(不常见)散列到桶中。此外,如果您的ID(例如)都可以被4整除,那么这可能会生成一个散列到bucket中的散列表。 hash_code%buckets 每四桶使用一次。

我更喜欢使用

this.Id.GetHashCode();

我认为这使得散列更可能被正确地分布,而不是直接使用ID。