Object.GetHashCode

Question

我的问题可能会重复Object.GetHashCode（）的默认实现，但我再问一次，因为我不理解那个问题的接受答案。

首先，我对上一个问题的接受答案有三个问题，引用了一些文档如下：

“但是，因为在垃圾回收期间回收对象后可以重用此索引，所以可以为两个不同的对象获取相同的哈希码。”

这是真的？ 在我看来，两个对象将不具有相同的哈希码，因为在对象被垃圾收集（即不再存在）之前不会重用对象的代码。

“另外，表示相同值的两个对象只有在完全相同的对象时才具有相同的哈希码。”

这是一个问题吗？ 例如，我想将一些数据与DOM树中的每个节点实例相关联。 为此，“节点”必须具有标识或哈希码，以便我可以将它们用作数据字典中的键。 是不是一个哈希码来识别它是否是“完全相同的对象”，即“引用相等而不是”值相等“，我想要什么？

“这个实现对于散列并不是特别有用;因此，派生类应该覆盖GetHashCode”

这是真的？ 如果它对散列不好，那么如果它有什么好处，为什么它甚至被定义为Object的方法呢？

---

我的最终（也许对我来说最重要的）问题是，如果我必须发明/覆盖具有“引用相等”语义的任意类型的GetHashCode（）实现，则以下是一个合理且良好的实现：

class SomeType
{
  //create a new value for each instance
  static int s_allocated = 0;
  //value associated with this instance
  int m_allocated;
  //more instance data
  ... plus other data members ...
  //constructor
  SomeType()
  {
    allocated = ++s_allocated;
  }
  //override GetHashCode
  public override int GetHashCode()
  {
    return m_allocated;
  }
}

---

编辑

仅供参考我使用以下代码测试它：

    class TestGetHash
    {
        //default implementation
        class First
        {
            int m_x;
        }
        //my implementation
        class Second
        {
            static int s_allocated = 0;
            int m_allocated;
            int m_x;
            public Second()
            {
                m_allocated = ++s_allocated;
            }
            public override int GetHashCode()
            {
                return m_allocated;
            }
        }
        //stupid worst-case implementation
        class Third
        {
            int m_x;
            public override int GetHashCode()
            {
                return 0;
            }
        }

        internal static void test()
        {
            testT<First>(100, 1000);
            testT<First>(1000, 100);
            testT<Second>(100, 1000);
            testT<Second>(1000, 100);
            testT<Third>(100, 100);
            testT<Third>(1000, 10);
        }

        static void testT<T>(int objects, int iterations)
            where T : new()
        {
            System.Diagnostics.Stopwatch stopWatch =
                System.Diagnostics.Stopwatch.StartNew();
            for (int i = 0; i < iterations; ++i)
            {
                Dictionary<T, object> dictionary = new Dictionary<T, object>();
                for (int j = 0; j < objects; ++j)
                {
                    T t = new T();
                    dictionary.Add(t, null);
                }
                for (int k = 0; k < 100; ++k)
                {
                    foreach (T t in dictionary.Keys)
                    {
                        object o = dictionary[t];
                    }
                }
            }
            stopWatch.Stop();
            string stopwatchMessage = string.Format(
                "Stopwatch: {0} type, {1} objects, {2} iterations, {3} msec",
                typeof(T).Name, objects, iterations,
                stopWatch.ElapsedMilliseconds);
            System.Console.WriteLine(stopwatchMessage);
        }
    }

在我的机器上，结果/输出如下：

First type, 100 objects, 1000 iterations, 2072 msec
First type, 1000 objects, 100 iterations, 2098 msec
Second type, 100 objects, 1000 iterations, 1300 msec
Second type, 1000 objects, 100 iterations, 1319 msec
Third type, 100 objects, 100 iterations, 1487 msec
Third type, 1000 objects, 10 iterations, 13754 msec

我的实现占用了默认实现的一半时间（但是我的类型因我的m_allocated数据成员的大小而变大）。

我的实现和默认实现都是线性扩展的。

相比之下，作为一个健全性检查，愚蠢的实施开始变坏并且变得更糟。

Answer 1

哈希代码实现必须具有的最重要的属性是：

如果两个对象相等，那么它们必须具有相同的哈希码。

如果你有一个类，通过引用相等比较类的实例，那么你不需要重写GetHashCode; 默认实现保证两个具有相同引用的对象具有相同的哈希代码。 （你在同一个对象上调用两次相同的方法，所以当然结果是一样的。）

如果您编写了一个实现与引用相等不同的自身相等的类，那么您需要重写GetHashCode，这样两个比较相等的对象具有相同的哈希码。

现在，您可以通过每次返回零来实现。 这将是一个糟糕的哈希函数，但它是合法的。

良好散列函数的其他属性是：

• GetHashCode永远不应该抛出异常

• 可变对象比较其可变状态的相等性，因此在其可变状态上进行哈希处理，这些对象很容易出错。 您可以将对象放入哈希表中，对其进行修改，并且无法再将其删除。 尝试永远不要散列或比较可变状态的相等性。

• GetHashCode应该非常快 - 请记住，良好的哈希算法的目的是提高查找的性能。 如果哈希很慢，则无法快速查找。

• 不相等的对象应具有不同的哈希码，在32位整数的整个范围内均匀分布

Answer 2

题：

这是真的？ 在我看来，两个对象将不具有相同的哈希码，因为在对象被垃圾收集（即不再存在）之前不会重用对象的代码。

如果默认的GetHashCode实现生成，则两个对象可以共享相同的哈希代码，因为：

1. 在对象的生命周期内不应更改默认的GetHashCode结果 ，默认实现可确保这一点。 如果它可以改变，像Hashtable这样的类型无法处理这种实现。 那是因为预期默认哈希码是唯一实例标识符的哈希码（即使没有这样的标识符:)）。
2. GetHashCode值的范围是整数范围（2 ^ 32）。

结论： 足够分配2 ^ 32个强引用对象（必须在Win64上很容易）才能达到极限。

最后， MSDN中的object.GetHashCode引用中有一个显式语句：GetHashCode方法的默认实现不保证不同对象的唯一返回值。 此外，.NET Framework不保证GetHashCode方法的默认实现，并且它返回的值在不同版本的.NET Framework之间是相同的。 因此，此方法的默认实现不得用作散列目的的唯一对象标识符。

Answer 3

实际上，您不需要修改只需要引用相等的类的任何内容。

而且，正式地说，这不是一个好的实施，因为它的分配很差。 散列函数应该具有合理的分布，因为它改进了散列桶分布，并且间接地改善了使用散列表的集合中的性能。 正如我所说，这是一个正式的答案，是设计哈希函数时的指导原则之一。