重写equals 方法的注意事项

Posted 2023-05-14

参考技术A 使用equals方法比较一个类的两个对象，希望能在逻辑上比较这两个对象是否相等，而不是比较这两个对象的引用是否相同，一般这个时候就需要重写equals方法了。

重写equals方法的注意事项写在了方法说明中，可以点击 这里 查看。

翻译过来的要点如下

是不是看着有点晕，没错，重写equasl方法看起来很简单，但是有很多种方式会导致重写出错。所以最好的做法是，没有必要不要重写equals方法。

如果一定要重写呢，有没有比较省力不容易出错的方法？答案是有的，那就是使用google 的AutoValue开源框架或者IDE自动生成功能。如果使用AutoValue框架，只需要在类上添加一个注解，框架就会自动帮你生成equals方法。

如果一定要自己重写，在重写之后要问自己三个问题：它是对称的吗?它是传递吗?它是一致的吗?（另外两个属性，自反性和非空性一般都都满足），然后还需要编写单元测试加以验证。下面是一个重写equals方法的例子：

另外，重写了equals方法，一定要重写hashCode方法。重写hashCode方法的注意事项，请看 这里 。

参考文章：

Effective Java 第三版——10. 重写equals方法时遵守通用约定

如何重写hashCode()和equals()方法

hashCode()和equals()方法可以说是Java完全面向对象的一大特色．它为我们的编程提供便利的同时也带来了很多危险．这篇文章我们就讨论一下如何正解理解和使用这２个方法．

 

如何重写equals()方法

如果你决定要重写equals()方法，那么你一定要明确这么做所带来的风险，并确保自己能写出一个健壮的equals()方法．一定要注意的一点是，在重写equals()后，一定要重写hashCode()方法．具体原因稍候再进行说明．

我们先看看 JavaSE 7 Specification中对equals()方法的说明：

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

这段话用了很多离散数学中的术数．简单说明一下：

1. 自反性：A.equals(A)要返回true.

2. 对称性：如果A.equals(B)返回true, 则B.equals(A)也要返回true.

3. 传递性：如果A.equals(B)为true, B.equals(C)为true, 则A.equals(C)也要为true. 说白了就是 A = B , B = C , 那么A = C.

4. 一致性：只要A,B对象的状态没有改变，A.equals(B)必须始终返回true.

5. A.equals(null) 要返回false.

 

相信只要不是专业研究数学的人，都对上面的东西不来电．在实际应用中我们只需要按照一定的步骤重写equals()方法就可以了．为了说明方便，我们先定义一个程序员类

1 class Coder {  
2     private String name;  
3     private int age;  
4       
5     // getters and setters  
6 }  

 

 

我们想要的是，如果２个程序员对象的name和age都是相同的，那么我们就认为这两个程序员是一个人．这时候我们就要重写其equals()方法．因为默认的equals()实际是判断两个引用是否指向内在中的同一个对象，相当于 == ．　重写时要遵循以下三步：

1. 判断是否等于自身.

 

1 if(other == this)  
2              return true; 

 

2. 使用instanceof运算符判断 other 是否为Coder类型的对象.

1 if(!(other instanceof Coder))  
2             return false;  

 

3. 比较Coder类中你自定义的数据域，name和age，一个都不能少.

1 Coder o = (Coder)other;  
2         return o.name.equals(name) && o.age == age;

 

 

看到这有人可能会问，第3步中有一个强制转换，如果有人将一个Integer类的对象传到了这个equals中，那么会不会扔ClassCastException呢？这个担心其实是多余的．因为我们在第二步中已经进行了instanceof 的判断，如果other是非Coder对象，甚至other是个null, 那么在这一步中都会直接返回false, 从而后面的代码得不到执行的机会．

上面的三步也是＜Effective Java＞中推荐的步骤，基本可保证万无一失．

 

 

如何重写hashCode()方法

在JavaSE 7 Specification中指出，

＂Note that it is generally necessary to override the hashCode method whenever this method（equals） is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.＂

 

如果你重写了equals()方法，那么一定要记得重写hashCode()方法．我们在大学计算机数据结构课程中都已经学过哈希表(hash table)了，hashCode()方法就是为哈希表服务的．

当我们在使用形如HashMap, HashSet这样前面以Hash开头的集合类时，hashCode()就会被隐式调用以来创建哈希映射关系．稍后我们再对此进行说明．这里我们先重点关注一下hashCode()方法的写法．

 

＜Effective Java＞中给出了一个能最大程度上避免哈希冲突的写法，但我个人认为对于一般的应用来说没有必要搞的这么麻烦．如果你的应用中HashSet中需要存放上万上百万个对象时，那你应该严格遵循书中给定的方法．如果是写一个中小型的应用，那么下面的原则就已经足够使用了：

要保证Coder对象中所有的成员都能在hashCode中得到体现．

对于本例，我们可以这么写：

1 @Override  
2     public int hashCode() {  
3         int result = 17;  
4         result = result * 31 + name.hashCode();  
5         result = result * 31 + age;  
6           
7         return result;  
8     }  

其中int result = 17你也可以改成20, 50等等都可以．看到这里我突然有些好奇，想看一下String类中的hashCode()方法是如何实现的．查文档知：

 

"Returns a hash code for this string. The hash code for a String object is computed as

 s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
 

using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)"

对每个字符的ASCII码计算n - 1次方然后再进行加和，可见Sun对hashCode的实现是很严谨的. 这样能最大程度避免２个不同的String会出现相同的hashCode的情况．

 

重写equals()而不重写hashCode()的风险

在Oracle的Hash Table实现中引用了bucket的概念．如下图所示：

 

从上图中可以看出，带bucket的hash table大致相当于哈希表与链表的结合体．即在每个bucket上会挂一个链表，链表的每个结点都用来存放对象．Java通过hashCode()方法来确定某个对象应该位于哪个bucket中，然后在相应的链表中进行查找．在理想情况下，如果你的hashCode()方法写的足够健壮，那么每个bucket将会只有一个结点，这样就实现了查找操作的常量级的时间复杂度．即无论你的对象放在哪片内存中，我都可以通过hashCode()立刻定位到该区域，而不需要从头到尾进行遍历查找．这也是哈希表的最主要的应用．

 

如：

当我们调用HashSet的put(Object o)方法时，首先会根据o.hashCode()的返回值定位到相应的bucket中，如果该bucket中没有结点，则将 o 放到这里，如果已经有结点了, 则把 o 挂到链表末端．同理，当调用contains(Object o)时，Java会通过hashCode()的返回值定位到相应的bucket中，然后再在对应的链表中的结点依次调用equals()方法来判断结点中的对象是否是你想要的对象．

 

下面我们通过一个例子来体会一下这个过程：

我们先创建２个新的Coder对象：

1 Coder c1 = new Coder("bruce", 10);  
2 Coder c2 = new Coder("bruce", 10); 

假定我们已经重写了Coder的equals()方法而没有重写hashCode()方法：

 

 1 @Override  
 2     public boolean equals(Object other) {  
 3         System.out.println("equals method invoked!");  
 4           
 5         if(other == this)  
 6             return true;  
 7         if(!(other instanceof Coder))  
 8             return false;  
 9           
10         Coder o = (Coder)other;  
11         return o.name.equals(name) && o.age == age;  
12     }  

 

然后我们构造一个HashSet，将c1对象放入到set中：

1 Set<Coder> set = new HashSet<Coder>();  
2         set.add(c1);  

 再执行:

1  System.out.println(set.contains(c2));  

我们期望contains(c2)方法返回true, 但实际上它返回了false.

c1和c2的name和age都是相同的，为什么我把c1放到HashSet中后，再调用contains(c2)却返回false呢？这就是hashCode()在作怪了．因为你没有重写hashCode()方法，所以HashSet在查找c2时，会在不同的bucket中查找．比如c1放到05这个bucket中了，在查找c2时却在06这个bucket中找，这样当然找不到了．因此，我们重写hashCode()的目的在于，在A.equals(B)返回true的情况下，A, B 的hashCode()要返回相同的值．

 

我让hashCode()每次都返回一个固定的数行吗

有人可能会这样重写：

1 @Override  
2     public int hashCode() {  
3         return 10;  
4   
5     } 

如果这样的话，HashMap, HashSet等集合类就失去了其 "哈希的意义"．用<Effective Java>中的话来说就是，哈希表退化成了链表．如果hashCode()每次都返回相同的数，那么所有的对象都会被放到同一个bucket中，每次执行查找操作都会遍历链表，这样就完全失去了哈希的作用．所以我们最好还是提供一个健壮的hashCode()为妙．

 

摘自：http://blog.csdn.net/neosmith/article/details/17068365