哈希码必须取决于所使用的相等定义，因此如果 A == B 则 A.GetHashCode() == B.GetHashCode()（但不一定是相反的；A.GetHashCode() == B.GetHashCode() 不包含 A == B）。
默认情况下，值类型的相等定义基于它的值，而引用类型的相等定义基于它的标识（也就是说，默认情况下，引用类型的实例只等于它自己），因此值类型的默认哈希码取决于它包含的字段的值*，而对于引用类型，它取决于标识。实际上，由于我们理想情况下希望不相等对象的哈希码不同，特别是在低位（最有可能影响重新哈希的值），我们通常想要两个等价但不相等的对象具有不同的哈希值。
由于一个对象将保持与自身相等，还应该清楚GetHashCode() 的这个默认实现将继续具有相同的值，即使对象发生了变异（即使对于可变对象，身份也不会发生变异） .
现在，在某些情况下，引用类型（或值类型）重新定义了相等性。一个例子是字符串，例如"ABC" == "AB" + "C"。尽管有两个不同的字符串比较实例，但它们被认为是相等的。在这种情况下，GetHashCode() 必须被覆盖，以便该值与定义相等性的状态相关（在这种情况下，包含的字符序列）。
虽然对同样不可变的类型执行此操作更为常见，但出于各种原因，GetHashCode() 不依赖于不可变性。相反，GetHashCode() 必须在面对可变性时保持一致 - 更改我们在确定散列时使用的值，散列 必须 相应地更改。但是请注意，如果我们使用这个可变对象作为使用散列的结构的键，这是一个问题，因为改变对象会改变它应该存储的位置，而不会将它移动到那个位置（这也是正确的集合中对象的位置取决于其值的任何其他情况 - 例如，如果我们对列表进行排序，然后改变列表中的一项，则列表不再排序）。然而，这并不意味着我们必须只在字典和哈希集中使用不可变对象。相反，这意味着我们不能改变这种结构中的对象，使其不可变是保证这一点的明确方法。
确实，在很多情况下，在这种结构中存储可变对象是可取的，只要我们在这段时间内不改变它们，就可以了。由于我们没有不变性带来的保证，因此我们希望以另一种方式提供它（例如，在集合中花费很短的时间并且只能从一个线程访问）。
因此，键值的不变性是可能的情况之一，但通常是一个想法。但是，对于定义哈希码算法的人来说，他们不能假设任何这种情况总是一个坏主意（他们甚至不知道在对象存储在这种结构中时发生了突变）；由他们实现在对象的当前状态上定义的哈希码，无论在给定点调用它是否好。因此，例如，不应该在可变对象上记忆哈希码，除非在每次变异时清除记忆。 （无论如何，记住哈希通常是一种浪费，因为重复命中相同对象哈希码的结构将有自己的记忆）。
现在，在手头的情况下，ArrayList 在基于身份的默认相等情况下运行，例如：
ArrayList a = new ArrayList();
ArrayList b = new ArrayList();
for(int i = 0; i != 10; ++i)
{
a.Add(i);
b.Add(i);
}
return a == b;//returns false
现在，这实际上是一件好事。为什么？好吧，你怎么知道我们要考虑 a 等于 b？我们可能会这样做，但在其他情况下也有很多充分的理由不这样做。
此外，将平等从基于身份重新定义为基于价值，比从基于价值重新定义为基于身份要容易得多。最后，对于许多对象，有不止一个基于值的相等定义（经典案例是关于什么使字符串相等的不同观点），因此甚至没有一个唯一有效的定义。例如：
ArrayList c = new ArrayList();
for(short i = 0; i != 10; ++i)
{
c.Add(i);
}
如果我们考虑上面的a == b，我们是否也应该考虑a == c？答案取决于我们在使用的平等定义中所关心的内容，因此框架无法知道所有情况的正确答案是什么，因为所有情况都不一致。
现在，如果我们确实关心给定情况下基于值的平等，我们有两个非常简单的选择。首先是继承和覆盖平等：
public class ValueEqualList : ArrayList, IEquatable<ValueEqualList>
{
/*.. most methods left out ..*/
public Equals(ValueEqualList other)//optional but a good idea almost always when we redefine equality
{
if(other == null)
return false;
if(ReferenceEquals(this, other))//identity still entails equality, so this is a good shortcut
return true;
if(Count != other.Count)
return false;
for(int i = 0; i != Count; ++i)
if(this[i] != other[i])
return false;
return true;
}
public override bool Equals(object other)
{
return Equals(other as ValueEqualList);
}
public override int GetHashCode()
{
int res = 0x2D2816FE;
foreach(var item in this)
{
res = res * 31 + (item == null ? 0 : item.GetHashCode());
}
return res;
}
}
这假设我们总是希望以这种方式处理此类列表。我们还可以为给定案例实现 IEqualityComparer：
public class ArrayListEqComp : IEqualityComparer<ArrayList>
{//we might also implement the non-generic IEqualityComparer, omitted for brevity
public bool Equals(ArrayList x, ArrayList y)
{
if(ReferenceEquals(x, y))
return true;
if(x == null || y == null || x.Count != y.Count)
return false;
for(int i = 0; i != x.Count; ++i)
if(x[i] != y[i])
return false;
return true;
}
public int GetHashCode(ArrayList obj)
{
int res = 0x2D2816FE;
foreach(var item in obj)
{
res = res * 31 + (item == null ? 0 : item.GetHashCode());
}
return res;
}
}
总结：
- 引用类型的默认相等定义仅依赖于标识。
- 大多数时候，我们想要这样。
- 当定义类的人认为这不是我们想要的，他们可以覆盖这个行为。
- 当使用该类的人再次想要不同的相等定义时，他们可以使用
IEqualityComparer<T> 和IEqualityComparer，以便他们的字典、哈希映射、哈希集等使用他们的相等概念。
- 如果对象是基于哈希的结构的关键，则对它进行变异是灾难性的。可以使用不变性来确保不会发生这种情况，但这不是强制性的，也不是总是可取的。
总而言之，该框架为我们提供了不错的默认设置和详细的覆盖可能性。
*在结构中使用小数的情况下存在一个错误，因为在某些情况下，结构安全时会使用快捷方式而不是其他情况，但包含小数的结构是一种情况捷径不安全，被错误地识别为安全的情况。