Effective C# Item 10: Understand the Pitfalls of GetHashCode()

Effective C# Item 10 : Understand the Pitfalls of GetHashCode()

      这是本书中唯一一项不推荐大家使用的函数。如果不是为哈希序列(例如HashTable和Dictionary)设定键(key)的话,我们应当尽量避免使用GetHashCode()。这是因为当基类调用GetHashCode时会产生一系列的问题。对于引用类型来说,它可以工作但是效率不高。对于值类型来说结果经常就是错误的。我们不能写出同时兼顾高效和正确的GetHashCode()方法。没有一个方法向它一样引起这么多的讨论和混乱。

      如果我们的类型没有在容器中被当作键来使用,那么不会有任何问题。Windows Form控件,Web控件,数据库链接之类不太可能会被当作键来使用。在这种情况下,我们什么也不做。所有的引用类型都会有自己的(哈希码)hash code。对于值类型来说是恒定值,虽然效率不高,但是还可以工作。而对于大多数我们自己创建的类型,我们应当尽量避免出现GetHashCode()方法。

      如果我们必须要创建一个用于哈希表中键的类型,那我们需要为它提供GetHashCode()方法。基于Hash的容器使用哈希码来优化搜索。每一个容器内的对象都包含一个整数值,称为哈希码。基于这些哈希码的值,对象被存储在被称为bucket(有的称其为哈希表元或桶)的列表中。当我们需要寻找对象的时候,通过哈希码就可以找到所对应的列表。在.Net中,所有对象都有其哈希码,源于System.Object.GetHashCode()。任何一个GetHashCode()方法应当遵循下面三条原则:

           1、如果两个对象相等,那么它们的哈希码应该相等。这是很显然的,不然我们就无法通过哈希码进行搜索了。

           2、对于任何对象,GetHashCode()返回的必须是一个恒量。不论被什么方法调用,他必须返回同样的值,我们必须要确保对象保存在一个正确的bucket中。

           3、对于所有的输入,GetHashCode()返回的应当是随机分配的,这有助于提高哈希表的效率。

      一个正确且高效的哈希函数需要确保以上三项条件。在System.Object和System.ValueType中定义的版本是有一些缺点的。Object.GetHashCode()使用System.Object内部字段来获得哈希码值。每当一个新的对象被创建,就会产生一个独一无二的整数型的键值。这些键值从1开始,每次有新对象创建的时候自增1。这些对象的标识是在System.Object被创建时候设置的,不能在之后对其进行修改。通过Object.GetHashCode()我们可以得到它的标识值,并将它作为对象的哈希码。

      我们现在来用这三条标准来检验一下Object.GetHashCode()是否符合要求。除非我们重写了==操作,不然对于两个相等对象,GetHashCode()会返回同样的值。==操作检查对象的地址,GetHashCode()返回对象的内部标识。如果我们重写了==,那么我们也必须相应的调整我们的GetHashCode()来确保符合第一条原则。

      对于第二条原则,由于内部字段的值是不能修改的,哈希码的值也不能修改。这一条是满足的。

      第三条原则要求在整数范围内随机取值,这点就不满足了。因为产生的数列并不是随机的,除非我们创建了非常庞大数量的对象。

      这就表示Object.GetHashCode()的结果是正确的,但是效率是不高的。如果我们创建了一个基于我们自定义的引用类型的哈希表,它将正确的工作,但是速度较慢。当我们要使用引用类型做为哈希表的键值时,我们应当重写GetHashCode()方法来获得更加离散的整数来做为哈希码值。

      对于值类型,下面有一个小例子来检验System.ValueType.GetHashCode()是否符合那三条原则。值类型的GetHashCode()返回类型中第一个字段的哈希码值做为类型的哈希码值:

public   struct  MyStruct
{
      
private string _msg;
      
private int _id;
      
private DateTime _epoch;
      
//属性略
}

      MyStruct对象返回的哈希码的值是由_msg字段决定的。下面这段代码始终返回true:

MyStruct s  =   new  MyStruct();
return  s.GetHashCode()  ==  s.Msg.GetHashCode();

      第一条原则规定如果两个对象相等,那么它们应当返回相同的值。对于值类型来说,同引用类型的情况比较类似。由于它是根据第一个成员来生成哈希码值,所以我们应当重写它的==运算符。当我们重定义的==运算符是通过比较第一个成员来进行判断的时候,它就能正常工作。如果第一个成员没有参与相等的判断,那么就违反了第一条原则。

      第二条要求生成的值必须是个恒量。只有第一个成员是不可变的类型可以满足这个原则。如果我们修改了它第一个成员的值,那么哈希码也会发生变化。这不符合第二条原则的规定。这也是为什么我们说应当在值类型中使用不可变类型成员的原因。(P.S. 关于不可变类型可以看一下 Item7: Prefer Immutable Atomic Value Types )

      第三条原则是否满足要看类型中第一个成员的类型。如果我们的类型中第一个成员都不相同,那么也许会产生比较随机的值。但是一旦我们的值类型的第一个成员的值相等,那么GetHashCode()返回的值也就相等,这条原则基本上也不满足。

public   struct  MyStruct
{
      
private DateTime _epoch;
      
private string _msg;
      
private int _id;
      
//属性略
}

      如果_epoch被设定为当前日期(只包括年月日),那么在同样日期创建的对象都拥有同样的哈希码值。

      总结一下我们发现,对于引用类型来说GetHashCode()虽然效率不高,但还是可以工作的。对于值类型来说只有在第一个成员是只读的时候会正常工作。只有在第一个成员的值比较随机的时候才会有较好的效率。

      如果我们希望创建一个较为优化的哈希码,我们必须为我们的类型添加一些制约。我们根据三条原则来重新实现GetHashCode()。

      首先,如果两个对象相等,那么它们应当返回相同的哈希码值。用于生成哈希码值的任何属性或数值也应当满足这个要求,这就是说我们要用在定义“相等”关系时用到的属性或数据来生成哈希码的值。有可能有的属性参与了“相等”判断,但是没有参加哈希码的生成。System.ValueType默认的情况下就是如此,这样可能会违背第三条原则。参与判断“相等”的属性和成员也应当参与到生成哈希码的运算中。

      其次,GetHashCode()返回的值必须是不可变的。下例中我们定义一个名为Customer的引用类型:

         public   class  Customer
        
{
            
private string _name;
            
private decimal _revenue;
            
public Customer(string name)
            
{
                _name 
= name;
            }

            
public string Name
            
{
                
get
                
{
                    
return _name;
                }

                
set
                
{
                    _name 
= value;
                }

            }

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


        }

      当我们执行了下面的程序之后:

Customer c1  =   new  Customer( " Acme Products " );
myHashMap.Add(c1, orders);
// 这里出现错误
c1.Name  =   " Acme Software "

      c1就从原有的myHashMap中失踪了。当我们将c1加myHashMa时,哈希码是根据字符串”Acme Products”生成的。当我们将它改成”Acme Software”时,哈希码也发生了变化。这个customer数据丢失是因为生成哈希码的成员不是不可变的。

      对于值类型来说,它出的错误与引用类型不同。如果c1是值类型,c1的一个拷贝被放在myHashMap中。当我们改变c1的值的时候,对于myHashMap中的c1并没有发生任何改变。由于在boxing和unboxing时发生了拷贝,所以对于值类型来说,我们在将其添加到哈希表中之后再修改其值就没有任何意义。

      想要满足原则2就需要使用一些不可变的属性来生成哈希码值。对于引用类型来说使用的是对象的地址,这是不可变的。对于值类型来说使用的是第一个成员,我们也希望这个成员是不可变的。除了将我们的类型定义为不可变类型之外,我们没有什么更好的方法。当我们在哈希表中使用一个值类型来做为键,那么这个值类型就应当是不可变类型。一旦违反了这一点,我们在哈希表中使用这些类型做为键值的时候就会发生问题。我们重新修改Customer类,现在我们将_name设为readonly:

         public   class  Customer
        
{
            
private readonly string _name;
            
private decimal _revenue;
            
public Customer(string name): this(name,0)
            
{
            }

            
public Customer(string name, decimal revenue)
            
{
                _name 
= name;
                _revenue 
= revenue;
            }

            
public string Name
            
{
                
get
                
{
                    
return _name;
                }

            }

            
public Customer ChangeName(string newName)
            
{
                
return new Customer(newName,_revenue);
            }

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

        }

      将name设为不可变就意味着我们在修改对象的时候必须这样做:

Customer c1  =   new  Customer( " Acme Products " );
myHashMap.Add(c1, orders);
// 当我们需要修改name时
Customer c2  =  c1.ChangeName( " Acme Software " );
Order o 
=  myHashMap[c1]  as  Order;
myHashMap.Remove(c1);
myHashMap.Add(c2, o);

      我们需要将原有的对象移除,再将新对象加入哈希表中。这样虽然比原来繁琐,但是它至少能正常工作,而前一个版本得到的结果是错误的。我们通过程序强迫使用者在修改对象内容时进行这些操作,就可以通过不可变的对象成员来生成新的哈希码的值。只有这样才能保证其正常工作。我们必须要确保用来计算哈希码值的对象成员是不可变的。

      第三条原则规定GetHashCode()返回的应当是在整数范围内的随机值。这要取决于我们创建的类型。很遗憾的是System.Object中想返回这样神奇的数并不容易。一般来说比较简易的算法是通过对类型中成员的值求异或(XOR)。我们不应当将类型中存在的一些易变成员加入到这个计算当中。

      GetHashCode()有着非常特殊的要求:相等对象返回相等的值,值必须恒定,返回的值的分布需要足够均匀。这几点只对不可变类型起作用(P.S. 返回值随机这个要求是很难达到的,第三条原则属于锦上添花类型的,虽然效率不高,但至少不会出错)。我们在使用的时候应当注意不要掉入GetHashCode()的陷阱之中。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

P.S.
      今天过生日了,先祝自己生日快乐~ 呵呵

      GetHashCode()方法和Equals()有密切的关系。如果我们重写了GetHashCode(),那么我们必须重写这个Equals(),来保证相等的对象具有相同的哈希码值。这是MSDN中说的,但是我还是有些疑惑,如果我们的类型重写了Equals(),又要用到哈希码的话,那么重写GetHashCode()理所应当,因为重写的Equals()已经改变了我们的类型的“相等”的概念,重写保证了相等对象的返回值相等。但是如果我们的类型重写了GetHashCode(),那为什么还“必须”重写Equals()呢?当然对于我们定义的类型来说,Equals()是有必要重写的,但是这个不是因为GetHashCode()吧...
      哈希码的值分布在Int32(-2,147,483,648 到 +2,147,483,647 之间的有符号整数)范围内,我们生成重写的哈希码也应当在这个范围内。对于值类型来说,如果这样写的话就会超出这个范围:

         struct  MyStruct
        
{
            
private long num;

            
public long Num
            
{
                
get
                
{
                    
return num;
                }

                
set
                
{
                    num 
= value;
                }

            }

        }

      对于这个类型,默认的GetHashCode()是基于第一个成员num来生成的。对于Int32及其范围之内的类型来说,返回值等于num的值。但是上例中num的范围超出了Int32的范围,这就可能会造成一些小麻烦。比如我下面这个例子:

MyStruct myStruct1  =   new  MyStruct();
MyStruct myStruct2 
=   new  MyStruct();
myStruct1.Num 
=   - 2147483648 ;
myStruct2.Num 
=   2147483647 ;

Console.WriteLine(myStruct1.GetHashCode());
Console.WriteLine(myStruct2.GetHashCode());

      两个不相等的实例得到的结果却相等,都是2147483647。对应这种情况我们可以使用XOR操作来合并它的高低位来返回,但是也是不能绝对保证不发生重复的,当然这种重复不会造成hashtable出错。

      回到目录

你可能感兴趣的:(hashCode())