为什么在重写 Equals 方法时重写 GetHashCode 很重要？

Question

给定以下类，

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null) 
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Which is preferred?

        return base.GetHashCode();

        //return this.FooId.GetHashCode();
    }
}

我重写了 Equals 方法，因为 Foo 代表 Foo 表的一行。 哪种方法是覆盖 GetHashCode 的首选方法？

为什么覆盖 GetHashCode 很重要？

Answer 1

从 .NET 4.7 开始，重写 GetHashCode() 的首选方法如下所示。 如果面向较旧的 .NET 版本，请包含 System.ValueTuple nuget 包。

// C# 7.0+
public override int GetHashCode() => (FooId, FooName).GetHashCode();

就性能而言，此方法将优于大多数复合哈希代码实现。 ValueTuple 是一个 struct 因此不会有任何垃圾，并且底层算法尽可能快。

Answer 2

怎么样：

public override int GetHashCode()
{
    return string.Format("{0}_{1}_{2}", prop1, prop2, prop3).GetHashCode();
}

假设性能不是问题:)

Answer 3

重写 Equals() 时，请不要忘记检查 obj 参数是否为 null。
还要比较类型。

public override bool Equals(object obj)
{
    Foo fooItem = obj as Foo;

    if (fooItem == null)
    {
       return false;
    }

    return fooItem.FooId == this.FooId;
}

原因是：Equals 与 null 比较时必须返回 false。 另请参阅 http://msdn.microsoft.com/en-us/library/bsc2ak47 .aspx

Answer 4

只是添加上面的答案：

如果您不覆盖 Equals，则默认行为是比较对象的引用。 这同样适用于哈希码 - 默认实现通常基于引用的内存地址。
因为您确实覆盖了 Equals，这意味着正确的行为是比较您在 Equals 上实现的任何内容，而不是引用，因此您应该对哈希码执行相同的操作。

您的类的客户端将期望哈希码具有与 equals 方法类似的逻辑，例如使用 IEqualityComparer 的 linq 方法首先比较哈希码，只有当它们相等时，才会比较 Equals() 方法，这可能会更昂贵运行时，如果我们没有实现 hashcode，相等的对象可能会有不同的 hashcode（因为它们有不同的内存地址），并且会被错误地确定为不相等（Equals() 甚至不会命中）。

此外，除了以下问题：如果您在字典中使用它，您可能无法找到您的对象（因为它是由一个哈希码插入的，当您查找它时，默认哈希码可能会有所不同，并且再次使用 Equals()甚至不会被调用，就像 Marc Gravell 在他的回答中解释的那样，您还引入了对字典或哈希集概念的违反，该概念不应允许相同的键 -
当您覆盖 Equals 时，您已经声明这些对象本质上是相同的，因此您不希望它们都作为数据结构上假设具有唯一键的不同键。 但由于它们具有不同的哈希码，因此“相同”的密钥将作为不同的密钥插入。

Answer 5

因为框架要求两个相同的对象必须有相同的hashcode。 如果重写 equals 方法对两个对象进行特殊比较，并且该方法认为两个对象相同，那么两个对象的哈希码也必须相同。 （字典和哈希表依赖于这个原则）。

Answer 6

我们有两个问题需要解决。

1. 如果以下字段中存在任何字段，则您无法提供合理的 GetHashCode()
   对象可以改变。 通常，一个对象永远不会被用于
   依赖于 GetHashCode() 的集合。 所以成本
   实现 GetHashCode() 通常不值得，或者根本不值得
   可能。

2. 如果有人将您的对象放入调用的集合中
   GetHashCode() 并且您已重写 Equals() 而无需进行
   GetHashCode() 以正确的方式行事，该人可能会花费数天时间
   跟踪问题。

因此默认情况下我会这样做。

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null)
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Some comment to explain if there is a real problem with providing GetHashCode() 
        // or if I just don't see a need for it for the given class
        throw new Exception("Sorry I don't know what GetHashCode should do for this class");
    }
}

Answer 7

哈希码用于基于哈希的集合，如 Dictionary、Hashtable、HashSet 等。此代码的目的是通过将特定对象放入特定组（桶）来非常快速地对其进行预排序。 当您需要从哈希集合检索该对象时，这种预排序非常有助于查找该对象，因为代码必须仅在一个存储桶中搜索您的对象，而不是在它包含的所有对象中搜索。 哈希码的分布越好（唯一性越好），检索速度越快。 在理想情况下，每个对象都有唯一的哈希码，找到它是一个 O(1) 操作。 在大多数情况下，它接近 O(1)。

Answer 8

这并不一定重要； 这取决于您的馆藏大小和性能要求，以及您的类是否将在您可能不知道性能要求的库中使用。 我经常知道我的集合大小不是很大，而且我的时间比通过创建完美哈希码获得的几微秒的性能更有价值； 所以（为了摆脱编译器发出的烦人的警告）我只需使用：（

   public override int GetHashCode()
   {
      return base.GetHashCode();
   }

当然我也可以使用#pragma来关闭警告，但我更喜欢这种方式。）

当你处于你的位置时确实需要比这里其他人提到的所有问题都适用的性能。 最重要 - 否则，当从哈希集或字典中检索项目时，您会得到错误的结果：哈希代码不得随对象的生命周期而变化（更准确地说，每当需要哈希码时，例如作为字典中的键时）：例如，以下内容是错误的，因为 Value 是公共的，因此可以在实例的生命周期内从外部更改到类，因此您不得将其用作哈希码的基础：

   class A
   {
      public int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //WRONG! Value is not constant during the instance's life time
      }
   }    

另一方面，如果值无法更改，则可以使用：

   class A
   {
      public readonly int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //OK  Value is read-only and can't be changed during the instance's life time
      }
   }

Answer 9

自 C# 9(.net 5或 .net core 3.1），您可能需要使用 记录，因为它基于值默认情况下平等。

Answer 10

您应该始终保证，如果两个对象相等（如 Equals() 所定义的那样），它们应该返回相同的哈希码。 正如其他一些评论所述，理论上，如果对象永远不会在基于哈希的容器（如 HashSet 或 Dictionary）中使用，则这不是强制性的。 不过，我建议您始终遵守这条规则。 原因很简单，因为对于某些人来说，出于实际提高性能或只是以更好的方式传达代码语义的良好意图，将集合从一种类型更改为另一种类型太容易了。

例如，假设我们在列表中保存一些对象。 一段时间后，有人实际上意识到 HashSet 是一个更好的选择，因为它具有更好的搜索特性。 这就是我们可能遇到麻烦的时候。 List 将在内部使用该类型的默认相等比较器，这意味着在您的情况下等于，而 HashSet 使用 GetHashCode()。 如果两者的行为不同，你的程序也会不同。 请记住，此类问题并不是最容易解决的。

我在博客文章中总结了这种行为以及其他一些 GetHashCode() 陷阱，您可以在其中找到更多信息示例和解释。

Answer 11

据我了解，原始的 GetHashCode() 返回对象的内存地址，因此如果您想比较两个不同的对象，则必须重写它。

编辑：
这是不正确的，原来的 GetHashCode() 方法不能保证 2 个值相等。 尽管相等的对象返回相同的哈希码。

Answer 12

在 .NET 中，当您重写 Equals() 方法时，建议也重写 GetHashCode()。 原因与.NET 在其内置数据结构中使用GetHashCode() 的方式有关。

当您将对象存储在基于哈希的集合（例如 Dictionary 或 HashSet）中时，.NET 使用 GetHashCode() 返回的值来组织其对象数据。 被视为相等的对象应返回相同的哈希码，从而在从此类集合中检索对象时提供最佳性能。

如果您重写 Equals()，您将更改使两个对象相等的定义。 因此，如果您不重写 GetHashCode()，您认为“相等”的对象可能会返回不同的哈希码。 当对象在基于哈希的集合中使用时，这可能会导致不一致的行为。 即使您知道它们在那里，也可能在集合中找不到它们，因为集合正在错误的哈希存储桶中查找。

让我们看一个例子。 假设您有一个 Person 类，并且您已重写 Equals() 来表示两个 Person 对象相等（如果它们的 Name< /code> 属性匹配。 但您忘记重写GetHashCode()。 现在，如果您将带有 Name="John" 的 Person 对象添加到 HashSet，然后尝试检查 Person 是否如果 HashSet 中存在 Name="John" 的 对象，它可能会返回 false，这是不正确的，因为 GetHashCode() 可能会返回对象引用的哈希码，而不是用于相等比较的 Name 字符串。

为了避免此问题，每当您重写 Equals() 时，您还应该重写 GetHashCode() 以确保它使用与 Equals() 相同的属性> 确实如此。 这将有助于在使用基于哈希的集合时保持一致性。

---

重写 GetHashCode() 需要生成一个哈希码，该哈希码考虑 Equals() 中使用的相同属性，并且均匀分布以防止哈希冲突。

以下是如何实现此目的的一个示例：

public override int GetHashCode()
{
   int hash = 17;

   // Suitable nullity checks etc, of course :)
   hash = (hash * 23) + field1.GetHashCode();
   hash = (hash * 23) + field2.GetHashCode();
   return hash;
}

在此示例中，field1 和 field2 是 Equals() 方法检查的字段。 常量 17 和 23 只是任意选择的“神奇”数字，通常会产生良好的结果。

您还可以在 C# 8.0 及更高版本中使用 HashCode.Combine()：

public override int GetHashCode()
{
    return HashCode.Combine(field1, field2);
}

请记住，GetHashCode() 的目标不是完全避免冲突，而是均匀分布冲突。 冲突是不可避免的，因为例如，可能的哈希码（2^32 for int）的数量小于可能的字符串值的数量。 但良好的哈希函数将有助于确保哈希码值的分布更加均匀并减少冲突的概率，从而在使用基于哈希的集合时获得更好的性能。

Answer 13

考虑到公共属性，下面使用反射在我看来是一个更好的选择，因为这样你就不必担心添加/删除属性（尽管不是很常见的情况）。 我发现这也表现得更好。（使用 Diagonistics 秒表比较时间）。

    public int getHashCode()
    {
        PropertyInfo[] theProperties = this.GetType().GetProperties();
        int hash = 31;
        foreach (PropertyInfo info in theProperties)
        {
            if (info != null)
            {
                var value = info.GetValue(this,null);
                if(value != null)
                unchecked
                {
                    hash = 29 * hash ^ value.GetHashCode();
                }
            }
        }
        return hash;  
    }

Answer 14

是的，如果您的项目将用作字典或 HashSet 等中的键，这一点很重要 - 因为它被使用（在没有自定义 IEqualityComparer 的情况下） ;) 将项目分组到存储桶中。 如果两个项目的哈希码不匹配，则它们可能永远被视为相等（Equals 永远不会被调用）。

GetHashCode() 方法应反映 Equals 逻辑； 规则是：

• 如果两个事物相等 (Equals(...) == true)，那么它们必须为 GetHashCode() 返回相同的值code>
• 如果 GetHashCode() 相等，则它们不必相同； 这是一个冲突，Equals 将被调用来看看它是否是真正的相等。

在本例中，“return FooId;”看起来是一个合适的 GetHashCode() 实现。 如果您正在测试多个属性，通常使用如下代码将它们组合起来，以减少对角线冲突（即，以便 new Foo(3,5) 具有与 不同的哈希码new Foo(5,3))：

在现代框架中，HashCode 类型具有帮助您从多个值创建哈希码的方法； 在较旧的框架上，您需要不需要，所以类似：

unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
    int hash = 13;
    hash = (hash * 7) + field1.GetHashCode();
    hash = (hash * 7) + field2.GetHashCode();
    ...
    return hash;
}

哦 - 为了方便起见，您还可以考虑在覆盖 == 和 != 运算符>等于 和GetHashCode。

---

此处演示了当您犯此错误时会发生什么。

Answer 15

实际上，正确实现 GetHashCode() 非常困难，因为除了 Marc 已经提到的规则之外，哈希码在对象的生命周期内不应更改。 因此，用于计算哈希码的字段必须是不可变的。

我在使用NHibernate的时候终于找到了这个问题的解决方案。
我的方法是根据对象的 ID 计算哈希码。 ID 只能通过构造函数设置，因此如果您想更改 ID（这种情况不太可能发生），您必须创建一个具有新 ID 和新哈希码的新对象。 此方法最适合 GUID，因为您可以提供随机生成 ID 的无参数构造函数。

Answer 16

通过重写Equals，您基本上是在声明您更好地了解如何比较给定类型的两个实例。

下面您可以看到 ReSharper 如何为您编写 GetHashCode() 函数的示例。 请注意，此代码片段旨在由程序员进行调整：

public override int GetHashCode()
{
    unchecked
    {
        var result = 0;
        result = (result * 397) ^ m_someVar1;
        result = (result * 397) ^ m_someVar2;
        result = (result * 397) ^ m_someVar3;
        result = (result * 397) ^ m_someVar4;
        return result;
    }
}

如您所见，它只是尝试根据类中的所有字段猜测一个好的哈希代码，但是如果您知道对象的域或值范围，您仍然可以提供一个更好的一个。