C#中Equals，GetHashCode方法和== 的分析

 

 

1. 通过运行结果可以看出，引用类型 （排除特殊的string类型）中即使所有属性值相同  他们的equals方法比较结果也是不一样。而且hashcode也是不一样，equals 默认的实现是比较两个对象的内存地址。（==操作符默认比较内存地址）值类型和string类型除外，因为所有值类型继承于System.ValueType()(System.ValueType()同样继承于Object，但是System.ValueType()本身却是引用类型)，而System.ValueType()对Equals()和==操作符进行了重写，是逐字节比较的。而string类型是比较特殊的引用类型，所以strIng在很多地方都是特殊处理的，此处就不做深究了。

2. 其实GetHashCode()在操作值类型的时候也是被System.ValueType()重写的。经过 测试的几个常用值类型来看，值类型的GetHashCode()基本都是原值输出(特指整数，Int32除外)。

从上图的结果可以看出，虽然string是引用类型，但是只要值一样，返回的HashCode也是一样的，这取决于它的特殊性。而我们自己写的类型Coordinates同样的值但返回的HashCode却不一样，我们可以简单的理解为是coor1与coor2的内存地址不同，所以CLR认为它们是不一样的。

Ps：在程序的生命周期中，相同的对象、变量返回的HashCode是相同的，并且是唯一的。但是绝对不允许做持久性存储，程序一旦结束并重新启动后，同样的对象无法获得上次程序运行时的HashCode。

重写对象Equals方法 需要同时重写 Gethashcode方法，不然会有警告 ，而且在用对象作 Dictionary的key 或者hashtable的时候会有问题。如果你没打算在代码中使用Dictionary或HashTable就无所谓写不写了，换句话说，如果要把引用类型做为Dictionary或HashTable的key使用时，必须重写这两个方法。原因：当我们把引用类型(string除外)做为Dictionary或HashTable的key时，有可能永远无法根据Key获得value的值，或者说两个类型的HashCode永远不会相等。就拿Dictionary来说，虽然我们存储的时候是键值对，但是CLR会先把key转成HashCode并且验证Equals后再做存储，根据key取值的时候也是把key转换成HashCode并且验证Equals后再取值，一定要注意验证时HashCode和Equals的关系是并且(&&)的关系。也就是说，只要GetHashCode和Equlas中有一个方法没有重写，在验证时没有重写的那个方法会调用基类的默认实现，而这两个方法的默认实现都是根据内存地址判断的，也就是说，其实一个方法的返回值永远会是false。

 

 

转载于:https://www.cnblogs.com/OneDirection/articles/7976762.html