blocks|key|465851|text|来自MSDN|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|465852|如果两个对象比较相等，则每个对象的GetHashCode方法必须返回相同的值。但是，如果两个对象的比较不相等，则两个对象的GetHashCode方法不必返回不同的值。
对象的GetHashCode方法必须始终如一地返回相同的哈希码，只要没有修改对象状态来确定对象的相等方法的返回值。请注意，这仅适用于应用程序的当前执行，如果应用程序再次运行，则可以返回不同的哈希代码。
为了获得最佳的性能，散列函数必须为所有输入生成随机分布。|blockquote|465853|这意味着，如果对象的值发生变化，则哈希代码应该更改。例如，将"+name“属性设置为"Tom”的"Person“类应该有一个哈希代码，如果将名称更改为”曾傑瑞“，则应该使用不同的代码。否则，汤姆==曾傑瑞，这可能不是你想要的。|465854|编辑：|style|BOLD|465855|也来自MSDN：|465856|重写GetHashCode的派生类还必须重写等于，以确保两个被视为相等的对象具有相同的哈希代码；否则，哈希表类型可能无法正常工作。|465857|来自MSDN哈希表条目|465858|键对象必须是不可变的，只要它们被用作Hashtable中的键。|465859|我读到这一点的方式是，可变对象应该在值变化时返回不同的哈希码，除非它们是设计用于哈希表中的。|465860|在System.Drawing.Point示例中，对象是可变的，并且在X或Y值更改时返回不同的哈希码。这将使它成为一个糟糕的候选人使用，因为-是在一个哈希表。|465861|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx|1|http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx^0|2|4|0|0|0|0|0|2|0|0|0|2|9|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|1D|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|1E|8|@$A|1F|B|1G|K|L]]|9|@]|C|$]]|$1|M|3|N|5|6|7|1H|8|@]|9|@]|C|$]]|$1|O|3|P|5|F|7|1I|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|S|3|T|5|F|7|1N|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1O|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|1P|8|@]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]|16|$5|11|12|13|C|$14|17]]]]

From <a href="http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx" rel="noreferrer">MSDN</a>

<blockquote>
 If two objects compare as equal, the
 GetHashCode method for each object
 must return the same value. However,
 if two objects do not compare as
 equal, the GetHashCode methods for the
 two object do not have to return
 different values. 
 
 The GetHashCode method for an object
 must consistently return the same hash
 code as long as there is no
 modification to the object state that
 determines the return value of the
 object's Equals method. Note that this
 is true only for the current execution
 of an application, and that a
 different hash code can be returned if
 the application is run again. 
 
 For the best performance, a hash
 function must generate a random
 distribution for all input.
</blockquote>

This means that if the value(s) of the object change, the hash code should change. For example, a "Person" class with the "Name" property set to "Tom" should have one hash code, and a different code if you change the name to "Jerry". Otherwise, Tom == Jerry, which is probably not what you would have intended.

<hr>

Edit: 

Also from MSDN:

<blockquote>
 Derived classes that override GetHashCode must also override Equals to guarantee that two objects considered equal have the same hash code; otherwise, the Hashtable type might not work correctly. 
</blockquote>

From <a href="http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx" rel="noreferrer">MSDN's hashtable entry</a>:

<blockquote>
 Key objects must be immutable as long as they are used as keys in the Hashtable. 
</blockquote>

The way I read this is that mutable objects should return different hashcodes as their values change, unless they are designed for use in a hashtable.

In the example of System.Drawing.Point, the object is mutable, and does return a different hashcode when the X or Y value changes. This would make it a poor candidate to be used as-is in a hashtable.

blocks|key|465913|text|不直接回答您的问题，但是-如果您使用Resharper，请不要忘记它有一个为您生成合理的GetHashCode实现(以及相等方法)的特性。当然，您可以指定在计算哈希代码时将考虑类的哪些成员。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|465914|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Not directly answering your question, but - if you use Resharper, do not forget it has a feature that generates a reasonable GetHashCode implementation (as well as the Equals method) for you. You can of course specify which members of the class will be taken into account when computing the hashcode.

blocks|key|767160|text|这是个好建议。以下是布莱恩·佩宾对这件事的看法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|767161|这使我不止一次被绊倒:确保GetHashCode总是在实例的整个生命周期中返回相同的值。请记住，在大多数哈希表实现中，哈希代码用于标识“桶”。如果对象的“桶”发生更改，哈希表可能无法找到您的对象。这些都是很难找到的错误，所以第一次就把它做对。|blockquote|767162|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|H|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

This is good advice. Here's what Brian Pepin has to say on the matter:

<blockquote>
 This has tripped me up more than
 once: Make sure GetHashCode always
 returns the same value across the
 lifetime of an instance. Remember that
 hash codes are used to identify
 "buckets" in most hashtable
 implementations. If an object's
 "bucket" changes, a hashtable may not
 be able to find your object. These can
 be very hard bugs to find, so get it
 right the first time.
</blockquote>

blocks|key|767192|text|哈希代码不会改变，但是理解哈希代码的来源也是很重要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|767193|如果您的对象使用值语义，即对象的标识由其值(如String、Color、all+structs)定义。如果对象的标识与其所有值无关，则通过其值的子集标识Hashcode。例如，StackOverflow条目存储在某个数据库中。如果您更改了您的名称或电子邮件，则您的客户条目将保持不变，尽管有些值已经更改(最终您通常会被某个长客户id+#识别)。|767194|因此，简而言之：|767195|值类型语义-+Hashcode由值引用类型语义定义，Hashcode由一些id定义。|767196|我建议您阅读Evans的“领域驱动设计”()，如果这仍然没有意义的话，他将进入实体和值类型(这或多或少就是我上面试图做的)。|767197|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

The hashcode never changes, but it's also important to understand where the Hashcode is coming from.

If your object is using value semantics, i.e. the object's identity is defined by its values (like String, Color, all structs). If your object's identity is independent of all of its values, then the Hashcode is identified by a subset of its values. For example, your StackOverflow entry is stored in a database somewhere. If you change your name or email, your customer entry stays the same, although some values have changed (ultimately you're usually identified by some long customer id #).

So in short:

Value type semantics - Hashcode is defined by values
Reference type semantics - Hashcode is defined by some id

I suggest you read Domain Driven Design by Eric Evans, where he goes into entities vs value types (which is more or less what I attempted to do above) if this still doesn't make sense.

blocks|key|466043|text|我认为有关GetHashcode的文档有点混乱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|466044|一方面，MSDN声明一个对象的哈希代码不应该改变，并且是常量的，另一方面，MSDN还指出，如果两个对象被认为相等，那么GetHashcode的返回值应该等于2个对象。|466045|MSDN：|offset|length|466046|散列函数必须具有以下属性：|blockquote|466047|如果两个对象比较相等，则每个对象的GetHashCode方法必须返回相同的值。但是，如果两个对象的比较不相等，则两个对象的GetHashCode方法不必返回不同的值。|unordered-list-item|466048|对象的GetHashCode方法必须始终如一地返回相同的哈希码，只要没有修改对象状态来确定对象的相等方法的返回值。请注意，这仅适用于应用程序的当前执行，如果应用程序再次运行，则可以返回不同的哈希代码。|466049|为了获得最佳的性能，散列函数必须为所有输入生成随机分布。|466050|然后，这意味着所有对象都应该是不可变的，或者GetHashcode方法应该基于不可变对象的属性。例如，假设您有这个类(朴素实现)：|466051|public+class+SomeThing
{
++++++public+string+Name+{get;+set;}

++++++public+override+GetHashCode()
++++++{
++++++++++return+Name.GetHashcode();
++++++}

++++++public+override+Equals(object+other)
++++++{
+++++++++++SomeThing+=+other+as+Something;
+++++++++++if(+other+==+null+)+return+false;
+++++++++++return+this.Name+==+other.Name;
++++++}
}|code-block|syntax|javascript|466052|此实现已经违反了MSDN中可以找到的规则。假设这个类有两个实例；instance1的Name属性设置为'Pol'，instance2的Name属性设置为'Piet‘。这两个实例返回不同的哈希代码，而且它们也不相等。现在，假设我将instance2的名称更改为'Pol'，那么根据我的Equals方法，这两个实例应该相等，并且根据MSDN的规则之一，它们应该返回相同的哈希码。|466053|但是，这是不可能的，因为instance2的哈希代码会改变，并且MSDN声明这是不允许的。|466054|然后，如果您有一个实体，您可以实现哈希代码，以便它使用该实体的“主标识符”，这可能是理想的代理键，或者是不可变的属性。如果您有一个值对象，则可以实现Hashcode，以便它使用该值对象的“属性”。这些属性构成了值对象的“定义”。这当然是一个值对象的本质；您不感兴趣的是它的身份，而是它的价值。|466055|因此，值对象应该是不可变的。(就像他们在.NET框架中，字符串，日期等.都是不可变的对象)。|466056|我想到的另一件事是：|466057|在“会话”(我不知道该如何调用它)期间，“GetHashCode”应该返回一个常量值。假设打开应用程序，从DB+(实体)加载对象的实例，并获取其哈希代码。它将返回一个特定的数字。关闭应用程序，加载相同的实体。这一次是否需要哈希码具有与第一次加载实体时相同的值？IMHO不是。|466058|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx^0|0|0|0|5|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1K|8|@]|9|@$F|1L|G|1M|1|1N]]|A|$]]|$1|H|3|I|5|J|7|1O|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|1Q|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|1R|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1S|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1T|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1U|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1V|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1W|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1X|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|1B|$1C|$5|1D|1E|1F|A|$1G|1H]]]]

I think that the documentation regarding GetHashcode is a bit confusing.

On one hand, MSDN states that the hashcode of an object should never change , and be constant
On the other hand, MSDN also states that the return value of GetHashcode should be equal for 2 objects, if those 2 objects are considered to be equal.

<a href="http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx" rel="nofollow noreferrer">MSDN:</a>

<blockquote>
 A hash function must have the following properties:
 
 <ul>
 <li>If two objects compare as equal, the GetHashCode method for each object
 must return the same value. However,
 if two objects do not compare as
 equal, the GetHashCode methods for the
 two object do not have to return
 different values.</li>
 <li>The GetHashCode method for an object must consistently return the
 same hash code as long as there is no
 modification to the object state that
 determines the return value of the
 object's Equals method. Note that this
 is true only for the current execution
 of an application, and that a
 different hash code can be returned if
 the application is run again.</li>
 <li>For the best performance, a hash function must generate a random
 distribution for all input.</li>
 </ul>
</blockquote>

Then, this means that all your objects should be immutable, or the GetHashcode method should be based on properties of your object that are immutable.
Suppose for instance that you have this class (naive implementation):

<pre><code>public class SomeThing
{
 public string Name {get; set;}

 public override GetHashCode()
 {
 return Name.GetHashcode();
 }

 public override Equals(object other)
 {
 SomeThing = other as Something;
 if( other == null ) return false;
 return this.Name == other.Name;
 }
}
</code></pre>

This implementation already violates the rules that can be found in MSDN.
Suppose you have 2 instances of this class; the Name property of instance1 is set to 'Pol', and the Name property of instance2 is set to 'Piet'.
Both instances return a different hashcode, and they're also not equal.
Now, suppose that I change the Name of instance2 to 'Pol', then, according to my Equals method, both instances should be equal, and according to one of the rules of MSDN, they should return the same hashcode. 
However, this cannot be done, since the hashcode of instance2 will change, and MSDN states that this is not allowed.

Then, if you have an entity, you could maybe implement the hashcode so that it uses the 'primary identifier' of that entity, which is maybe ideally a surrogate key, or an immutable property.
If you have a value object, you can implement the Hashcode so that it uses the 'properties' of that value object. Those properties make up the 'definition' of the value object. This is of course the nature of a value object; you're not interested in it's identity, but rather in it's value. 
And, therefore, value objects should be immutable. (Just like they are in the .NET framework, string, Date, etc... are all immutable objects).

Another thing that comes in mind: 
During which 'session' (I don't know really how I should call this) should 'GetHashCode' return a constant value.
Suppose you open up your application, load an instance of an object out of the DB (an entity), and get its hashcode. It will return a certain number.
Close the application, and load the same entity. Is it required that the hashcode this time has the same value as when you loaded the entity the first time ?
IMHO, not.

blocks|key|2000213|text|请看的博客文章：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2000214|VTO，RTOs和GetHashCode()+--哦，我的！|offset|length|2000215|然后查看后续文章(无法链接，因为我是新的，但在initlal文章中有一个链接)，它将进一步讨论并讨论初始实现中的一些小缺点。|2000216|这是我需要了解的关于创建GetHashCode()实现的所有信息，他甚至提供了他的方法的下载以及其他一些实用工具，简而言之。|2000217|entityMap|0|LINK|mutability|MUTABLE|url|http://musingmarc.blogspot.com/2007/08/vtos-rtos-and-gethashcode-oh-my.html^0|0|0|U|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Check out this blog post from Marc Brooks:

<a href="http://musingmarc.blogspot.com/2007/08/vtos-rtos-and-gethashcode-oh-my.html" rel="noreferrer">VTOs, RTOs and GetHashCode() -- oh, my!</a>

And then check out the follow up post (can't link as I'm new, but there's a link in the initlal article) which discusses further and covers some minor weaknesses in the initial implementation.

This was everything I needed to know about creating a GetHashCode() implementation, he even provides a download of his method along with some other utilities, in short gold.

blocks|key|2000303|text|这是一个很长的时间，但我认为仍然有必要给这个问题一个正确的答案，包括解释为什么和如何。到目前为止，最好的答案是引用MSDN+--不要试图制定自己的规则，MS的人知道他们在做什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2000304|但首先要做的是:问题中引用的指导方针是错误的。|2000305|为什么-有两个人|2000306|首先为什么是：如果哈希代码是以某种方式计算的，那么在对象的生存期内，它不会改变，即使对象本身发生了变化，它也会破坏相等的契约。|offset|length|style|BOLD|2000307|记住：“如果两个对象比较为相等，则每个对象的GetHashCode方法必须返回相同的值。但是，如果两个对象的比较不相等，则两个对象的GetHashCode方法不必返回不同的值。”|2000308|第二句常常被误解为“唯一的规则是，在创建对象时，平等对象的哈希码必须相等”。我不知道为什么，但这也是大多数答案的本质所在。|2000309|假设有两个包含名称的对象，其中的名称在equals方法中使用:同名->相同的东西。创建实例A:+Name+=+Joe创建实例B:+Name+=+Peter|2000310|Hashcode+A和Hashcode+B很可能不一样。当实例B的名称改为Joe时，现在会发生什么情况？|2000311|根据问题的指导方针，B的哈希码不会改变。其结果是:+A.Equals(B)+==>+true，但同时:+A.GetHashCode()+==+B.GetHashCode()+==>+false。|2000312|但是，确切地说，这种行为是平等&hashcode-契约明确禁止的。|2000313|第二个原因是：尽管哈希代码中的更改可能会使用哈希代码破坏散列和其他对象，但反过来也是正确的。在最坏的情况下，不更改哈希代码将得到散列列表，其中许多不同的对象都将具有相同的哈希代码，因此在使用标准值初始化对象时也会发生。|2000314|现在来看一下如何--乍一看，似乎存在矛盾--无论哪种方式，代码都会中断。但是，这两个问题都不是由修改或未修改的哈希代码造成的。|2000315|MSDN很好地描述了问题的根源：|2000316|来自MSDN的哈希表条目：|2000317|键对象必须是不可变的，只要它们被用作Hashtable中的键。|blockquote|2000318|这确实意味着：|2000319|任何创建哈希值的对象都应该在对象更改时更改哈希值，但当它在Hashtable中使用(当然也不能使用任何其他哈希对象)时，它绝对不能允许对其自身进行任何更改。|2000320|首先，最简单的方法当然是只为hashtable中使用的不可变对象设计，这些对象将在需要时作为普通的、可变的对象创建。在不可变对象中，缓存哈希代码显然是可以的，因为它是不可变的。|2000321|其次，如何或给对象一个“您现在就散列”-flag，确保所有对象数据都是私有的，检查所有可以更改对象数据的函数中的标志，如果不允许更改(即设置标志)，则抛出异常数据。现在，当您将对象放置在任何散列区域时，请确保设置标志，以及--以及--在不再需要时解除标志。为了便于使用，我建议在"GetHashCode“方法中自动设置标志-这样就不会忘记它。对"ResetHashFlag“方法的显式调用将确保程序员现在必须考虑是否允许更改对象数据。|2000322|好的，应该说的是:在某些情况下，有可能拥有具有可变数据的对象，在这些情况下，当对象数据被更改时，哈希代码仍然保持不变，而不违反等于&+hashcode+-契约。|2000323|然而，这确实要求，也不基于可变数据。因此，如果我编写一个对象，并创建一个只计算一次值并将其存储在对象中以便在以后调用时返回它的GetHashCode方法，那么我必须再次:绝对必须创建一个相等的方法，该方法将使用存储的值进行比较，这样A.Equals(B)也不会从false变为true。否则，合同就会被打破。这样做的结果通常是等于方法没有任何意义-它不是原始引用等于，但它也不是一个值等于。有时，这可能是有意的行为(即客户记录)，但通常不是。|2000324|因此，当对象数据发生变化时，只需更改GetHashCode结果，如果使用列表或对象在散列中使用对象(或仅仅可能)，则使对象不可变或创建一个只读标志，用于包含该对象的散列列表的生存期。|2000325|(顺便说一句:所有这些都不是C#+oder+.NET特定的-在所有哈希表实现的本质上，或者更一般的任何索引列表中，当对象在列表中时，对象的标识数据不应该改变。如果违反此规则，则会发生意外和不可预测的行为。在某些地方，可能有列表实现，它们监视列表中的所有元素，并自动重新索引列表--但这些实现的性能最好是可怕的。)|2000326|entityMap^0|0|0|0|0|6|0|0|0|0|0|0|0|0|6|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1T|8|@$H|1U|I|1V|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1W|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1X|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|20|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|21|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|22|8|@$H|23|I|24|J|K]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|25|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|26|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|27|8|@]|9|@]|A|$]]|$1|15|3|16|5|17|7|28|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|29|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|2H|8|@]|9|@]|A|$]]]|1P|$]]

It's been a long time, but nevertheless I think it is still necessary to give a correct answer to this question, including explanations about the whys and hows. The best answer so far is the one citing the MSDN exhaustivly - don't try to make your own rules, the MS guys knew what they were doing.

But first things first:
The Guideline as cited in the question is wrong. 

Now the whys - there are two of them

First why:
If the hashcode is computed in a way, that it does not change during the lifetime of an object, even if the object itself changes, than it would break the equals-contract.

Remember:
"If two objects compare as equal, the GetHashCode method for each object must return the same value. However, if two objects do not compare as equal, the GetHashCode methods for the two object do not have to return different values."

The second sentence often is misinterpreted as "The only rule is, that at object creation time, the hashcode of equal objects must be equal". Don't really know why, but that's about the essence of most answers here as well.

Think of two objects containing a name, where the name is used in the equals method: Same name -> same thing.
Create Instance A: Name = Joe
Create Instance B: Name = Peter

Hashcode A and Hashcode B will most likely not be the same.
What would now happen, when the Name of instance B is changed to Joe?

According to the guideline from the question, the hashcode of B would not change. The result of this would be:
A.Equals(B) ==> true
But at the same time:
A.GetHashCode() == B.GetHashCode() ==> false.

But exactly this behaviour is forbidden explicitly by the equals&amp;hashcode-contract.

Second why:
While it is - of course - true, that changes in the hashcode could break hashed lists and other objects using the hashcode, the reverse is true as well. Not changing the hashcode will in the worst case get hashed lists, where all of a lot of different objects will have the same hashcode and therefor be in the same hash bin - happens when objects are initialized with a standard value, for example.

<hr>

Now coming to the hows
Well, on first glance, there seems to be a contradiction - either way, code will break.
But neither problem does come from changed or unchanged hashcode.

The source of the problems is well described in the MSDN:

From MSDN's hashtable entry: 

<blockquote>
 Key objects must be immutable as long
 as they are used as keys in the
 Hashtable.
</blockquote>

This does mean:

Any object that creates a hashvalue should change the hashvalue, when the object changes, but it must not - absolutely must not - allow any changes to itself, when it is used inside a Hashtable (or any other Hash-using object, of course).

First how
Easiest way would of course be to design immutable objects only for the use in hashtables, that will be created as copys of the normal, the mutable objects when needed.
Inside the immutable objects, it's obviusly ok to cache the hashcode, since it's immutable.

Second how
Or give the object a "you are hashed now"-flag, make sure all object data is private, check the flag in all functions that can change objects data and throw an exception data if change is not allowed (i.e. flag is set). 
Now, when you put the object in any hashed area, make sure to set the flag, and - as well - unset the flag, when it is no longer needed.
For ease of use, I'd advise to set the flag automatically inside the "GetHashCode" method - this way it can't be forgotten. And the explicit call of a "ResetHashFlag" method will make sure, that the programmer will have to think, wether it is or is not allowed to change the objects data by now.

Ok, what should be said as well: There are cases, where it is possible to have objects with mutable data, where the hashcode is nevertheless unchanged, when the objects data is changed, without violating the equals&amp;hashcode-contract.

This does however require, that the equals-method is not based on the mutable data as well.
So, if I write an object, and create a GetHashCode method that does calculate a value only once and stores it inside the object to return it on later calls, then I must, again: absolutely must, create a Equals method, that will use stored values for the comparison, so that A.Equals(B) will never change from false to true as well. Otherwise, the contract would be broken. The result of this will usually be that the Equals method doesn't make any sense - it's not the original reference equals, but it is neither a value equals as well. Sometimes, this may be intended behaviour (i.e. customer records), but usually it is not.

So, just make GetHashCode result change, when the object data changes, and if the use of the object inside of hash using lists or objects is intended (or just possible) then make the object either immutable or create a readonly flag to use for the lifetime of a hashed list containing the object.

(By the way: All of this is not C# oder .NET specific - it is in the nature of all hashtable implementations, or more generally of any indexed list, that identifying data of objects should never change, while the object is in the list. Unexpected and unpredictable behaviour will occur, if this rule is broken. Somewhere, there may be list implementations, that do monitor all elements inside the list and do automatic reindexing the list - but the performance of those will surely be gruesome at best.)

blocks|key|2000339|text|请看埃里克·利珀特的GetHashCode指南和规则|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2000340|entityMap|0|LINK|mutability|MUTABLE|url|http://ericlippert.com/2011/02/28/guidelines-and-rules-for-gethashcode/^0|A|G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Check out <a href="http://ericlippert.com/2011/02/28/guidelines-and-rules-for-gethashcode/" rel="nofollow">Guidelines and rules for GetHashCode</a> by Eric Lippert

I read in the Essential C# 3.0 and .NET 3.5 book that:

<blockquote>
 GetHashCode()’s returns over the life of a particular object should be
 constant (the same value), even if the object’s data changes. In many
 cases, you should cache the method return to enforce this.
</blockquote>

Is this a valid guideline?

I have tried a couple built-in types in .NET and they didn't behave like this.

GetHashCode Guidelines in C#

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在必要的C# 3.0和.NET 3.5中读到：GetHashCode()在特定对象生命周期内的返回应该是常数(相同的值)，即使对象的数据发生了变化。在许多情况下，您应该缓存方法返回以强制执行此操作。这是一个有效的指引吗？我在.NET中尝试过几个内置类型，但它们的行为并不像这样。

问GetHashCode在C#中的指南
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GetHashCode在C#中的指南EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GetHashCode在C#中的指南
EN