Java：所有的equals方法实现都是错误的【转】

【51CTO快译】本文介绍了一种改写（override）equals 方法的技巧。使用该技巧，即使在实体类的子类添加了新的域（field）时，仍然能够满足 equals 方法的约定。

在《Effective Java》一书的第 8 条目中，Josh Bloch 将子类化时满足 equals 约定这一困难描述为：面向对象语言中等值关系的最根本问题。Bloch 这样写道：

不存在一种方式，能够在扩展非实例类并添加值组件的同时，仍然满足equals的约定。除非你愿意放弃面向对象的抽象性这一优点。

《Programming in Scala》一书中的第 28 章提供了一种方法，子类可以对非实例类进行扩展，添加值组件，而同时满足 equals 约定。虽然书中提供的那种技巧是用于定义 Scala 类，但一样适用于 Java 中的 类定义。在本文中，为了讲解这种方法，我将使用《Programming in Scala》中相关章节，改编相关的文本，并将原书中的 Scala 示例代码转换为了 Java 代码。

常见的等值陷阱

Class java.lang.Object 定义了一个 equals 方法，其中的子类可以进行改写（override）。不幸的是，最终的结果表明，在面向对象语言中，编写正确的等值方法相当困难。事实上，在对 Java 代码的大量正文进行研究之后，几位作者在 2007 年的一份论文中作出如下结论：几乎所有 equals 方法的实现都是错误的。

这是一个严重的问题，因为等值方法是很多代码的根本。其一，对于类型 C，一个错误的等值方法可能意味着，你不能可靠地将一个类型 C 的对象放入集合中。你可能有两个等值的类型 C 元素 elem1、elem2，即“em1.equals(elem2)”输出 true。然而，在下面的示例中，equals 方法的实现就是一种常见的错误：

 Set< C> hashSet =  new    java.util.HashSet< C>();
 hashSet.add(elem1);
 hashSet.contains(elem2);  // 返回 false！

存在四种常见的陷阱，它们都会在改写equals时导致非一致性的行为：

◆使用错误的原型对equals进行定义。

◆更改equals而未同时更改 hashCode。

◆对equals进行定义时涉及可变域（field）。

◆未能成功地将equals定义为等值关系。

这四种陷阱将在下文中具体讲述。

陷阱 1：使用错误的原型对equals进行定义

在下面的代码中，我们将为普通点的类添加一个等值方法：

 public     class    Point {

   private     final     int    x;
   private     final     int    y;

   public    Point( int    x,  int    y) {
   this   .x = x;
   this   .y = y;
  }

   public     int    getX() {
   return    x;
  }

   public     int    getY() {
   return    y;
  }

   // ...
 }

一个显而易见的错误定义如下：

 // 一个完全错误的 equals 定义
 public     boolean    equals(Point other) {
   return    ( this   .getX() == other.getX() &&  this   .getY() == other.getY());
 }

这种方法的错误之处是什么？初一看，它可以正常运行：

 Point p1 =  new    Point( 1  ,  2  );
 Point p2 =  new    Point( 1  ,  2  );

 Point q =  new    Point( 2  ,  3  );

 System.out.println(p1.equals(p2));  // prints true

 System.out.println(p1.equals(q));  // 输出 false

然而，一旦你将point放入集合中，问题就出来了：

 import    java.util.HashSet;

 HashSet< Point> coll =  new    HashSet< Point>();
 coll.add(p1);

 System.out.println(coll.contains(p2));  // 输出 false

coll 怎么可能不包含 p2 呢？你已经将 p1 添加到其中，而 p1 等于 p2。在下面的互操作中，进行比较的点的具体类型被隐藏，这时，导致问题的原因将清晰可见。将 p2a 定义为 p2 的别名，但使用的是 Object 类型而不是 Point：

 Object p2a = p2;

现在，如果你重复第一个比较，使用别名 p2a 而不是 p2，结果是：

 System.out.println(p1.equals(p2a));  // 输出 false

哪里出错了呢？事实上，由于类型不同，之前指定的 equals 版本并没有改写标准方法 equals。下面是在根类 Object 中定义的 equals 方法：

 public     boolean    equals(Object other)

由于 Point 中的 equals 方法使用 Point 而不是 Object 作为参数，因此，它并未对 Object 中的 equals 进行改写。相反，它只是一种重载的替代方法。Java 中重载由参数的静态类型解析，而不是运行时（run-time）类型。因此，只要参数的静态类型是 Point，就调用 Point 中的 equals 方法。同样，如果静态参数是 Object 类型，就调用 Object 中的 equals 方法。该方法没有被改写，因此在对 object 参数进行比较时，仍使用该方法。这就是“p1.equals(p2a)”输出 false 的原因，即使点 p1 和 p2a 具有相同的 x 和 y 值。这也是为什么在 HashSet 中 contains 方法返回 false 的原因。该方法是针对对常规集合进行操作，因此它会调用 Object 中的常规 equals 方法，而不是 Point 中重载的方法变种。

下面的代码定义了一个更好的equals方法：

 // 一个更好的定义，但仍不是完美的
 @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = ( this   .getX() == that.getX() &&  this   .getY() == that.getY());
  }
   return    result;
 }

现在，equals 具有了正确的类型。它将 Object 类型的值作为参数并输出一个 boolean 结果。该方法的实现使用了 instanceof 和 cast（类型转换）。它首先检测其他（other）对象是否为 Point 类型。如果是，它将对这 2 个点的坐标进行比较，然后返回结果。否则，输出为 false。

陷阱2 ：更改equals而未同时更改hashCode

如果你使用 Point 的最新定义，再次对 p1和 p2a 进行比较，将会得到期望中的结果：true。但是，如果你重复 HashSet.contains 测试，结果仍可能是 false：

 Point p1 =  new    Point( 1  ,  2  );
 Point p2 =  new    Point( 1  ,  2  );

 HashSet< Point> coll =  new    HashSet< Point>();
 coll.add(p1);

 System.out.println(coll.contains(p2));  // （很可能）输出 false

事实上，输出结果不是百分百确定。你也可能从测试中得到true值。如果得到的结果是true，你可以试试另外一些坐标为1和2的点。最终，你将会找到一个未包含在集合中的点。这里出现错误的原因是，Point重定义了equals而没有对hashCode进行重定义。

请注意，上述实例中的集合为HashSet。这表示，集合中元素被放在由相应的散列码决定的哈希桶（hash bucket）中。在contains测试中，它首先查找散列桶，然后对哈希桶中的所有元素和指定元素进行比较。现在，Point类的最新版本确实对 equals进行了重定义，但它没有同时对hashCode进行重定义。所以 hashCode 仍然保持 Object 类中其版本的值：分配对象地址的某种变化格式。p1 和 p2 的散列码几乎肯定是不同，即使这两个点的域（field）是相同的。不同的散列码意味着集合中散列桶具有较高概率的非重复性。contains 测试将根据 p2 的散列码在相应的散列桶中查找匹配的元素。大多数情况下，点 p1 会位于另一个散列桶中，因此绝不会找到它。p1 和 p2 有可能很偶然地位于同一散列桶中。对于这种情况，测试将返回ture 值。

问题在于，Point 的上次实现违法了Object 类中定义的hashCode约定：

如果两个对象根据equals(Object) 方法是等值的，那么对两个对象中任何一个调用 hashCode 方法都必须得到相同的整型结果。

事实上，在Java中，通常应同时对 hashCode 和equals进行重定义,这一事实是广为人知的。此外，hashCode 可能仅依赖equals所依赖的域。对于 Point 类，以下将是一个合适的 hashCode 定义：

 public     class    Point {

   private     final     int    x;
   private     final     int    y;

   public    Point( int    x,  int    y) {
   this   .x = x;
   this   .y = y;
  }

   public     int    getX() {
   return    x;
  }

   public     int    getY() {
   return    y;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = ( this   .getX() == that.getX() &&  this   .getY() == that.getY());
  }
   return    result;
  }

   @Override    public     int    hashCode() {
   return    ( 41   * ( 41   + getX()) + getY());
  }
 }

这只是 hashCode 多种可能的实现中的一种。将常量 41 加到一个整型域 x 上，所得结果再乘以素数 41，然后在加上另一个整型域 y。这样就可以提供合理分布的散列码，而运行时间和代码大小也会降低。

在定义与 Point 相似的类时，添加 hashCode 解决了等值的问题。但是，还有其他的问题需要注意。

陷阱 3 ：对equals进行定义时涉及可变域

以下对 Point 类进行一项细微的修改：

 public     class    Point {

   private    int   x;
   private    int    y;

   public    Point( int    x,  int    y) {
   this   .x = x;
   this   .y = y;
  }

   public     int    getX() {
   return    x;
  }

   public     int    getY() {
   return    y;
  }

   public     void    setX( int    x) {
   this   .x = x;
  }

   public     void    setY( int    y) {
   this   .y = y;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = ( this   .getX() == that.getX() &&  this   .getY() == that.getY());
  }
   return    result;
  }

   @Override    public     int    hashCode() {
   return    ( 41   * ( 41   + getX()) + getY());
  }
 }

唯一的不同之处是域 x 和 y 不再是 final 类型，同时添加了两个集合方法，允许用户更改 x 和 y 值。现在，equals和 hashCode 方法的定义涉及了这些可变域，因此域更改时它们的结果也将改变。一旦你将点放入集合中，这会带来很奇怪的效果：

 Point p =  new    Point( 1  ,  2  );

 HashSet< Point> coll =  new    HashSet< Point>();
 coll.add(p);

 System.out.println(coll.contains(p));  // 输出 true

现在，如果更改点 p 中的域，集合还将包含该点吗？ 我们来试试下面的代码：

 p.setX(p.getX() +  1  );

 System.out.println(coll.contains(p));  // （很可能）输出 false

这看起来很奇怪。p 到哪里去了？如果你对集合的 iterator 是否包含 p 进行测试，会得到各位奇怪的结果：

 Iterator< Point> it = coll.iterator();
 boolean    containedP =  false   ;
 while    (it.hasNext()) {
  Point nextP = it.next();
   if    (nextP.equals(p)) {
  containedP =  true   ;
   break   ;
  }
 }

 System.out.println(containedP);  // 输出 true

此处的集合不包含 p，但 p 却在该集合的元素之中！发生了什么事呢？在更改 x 域之后，点 p 最后被放在了该集合 coll 下错误的散列桶中。也就是，其初始散列桶与散列码的新值已不再对应。在某种意义上可以说，点 p 在集合 coll 中消失了，即使它仍然是集合中元素。

从这个示例得出的教训就是，当equals和 hashCode 取决于可变状态时，可能会为用户带来问题。如果他们将这种对象放入集合中，必须小心，不要修改决定性的状态。而这是很棘手的。如果你现在需要进行一个比 较，要考虑到对象的当前状态，通常不应直接使用 equals，而是使用其他命名。 对于 Point 的上一个定义，更为可取的是省略 hashCode 的重定义，并且命名比较方法 equalContents，或者使用其他不同于equals的命名。 这样，Point 将能够继承equals和 hashCode 的缺省实现。

陷阱 4：未能成功地将equals定义为等值关系

Object 中equals的约定指出 equals 必须实现非空对象的等值关系：

◆自反性 ：对于如何非空值 x，表达式 x.equals(x) 应返回true。

◆对称性 ：对于任何非空值：x 和 y，x.equals(y) 应返回true，当且仅当 y.equals(x) 返回 true。

◆传递性 ：对于任何非空值 x、y、z，如果 x.equals(y)返回 true 并且 y.equals(z) 返回 true，那么x.equals(z) 应返回 true。

◆一致性 ：对于任何非空值：x 和 y，多次调用 x.equals(y)应始终返回 true 或始终返回 false，如果对象的equals比较中所用信息未被修改。

◆对于任何非空值 x，x.equals(null) 应返回 false。

目前，对于 Point 类所使用的equals定义满足了equals的约定。然而，一旦涉及子类，事情将变得更加复杂。比如说，Point 有一个子类 ColoredPoint，其中添加了一个 Color 类型的域 color。假定将 Color 定义为枚举类型：

 public     enum    Color {
  RED, ORANGE, YELLOW, GREEN, BLUE, INDIGO, VIOLET;
 }

ColoredPoint 改写 equals，并添加新的 color 域：

 public     class    ColoredPoint  extends    Point {  // 问题：equals 不对称

   private     final    Color color;

   public    ColoredPoint( int    x,  int    y, Color color) {
   super   (x, y);
   this   .color = color;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    ColoredPoint) {
  ColoredPoint that = (ColoredPoint) other;
  result = ( this   .color.equals(that.color) &&  super   .equals(that));
  }
   return    result;
  }
 }

很多程序员都可能这样编写代码。请注意，在这种情况下，类 ColoredPoint 不必改写 hashCode。因为 ColoredPoint 的equals的新定义比 Point 中被改写的定义更为严格（意味着等值的对象更少），hashCode 的约定仍然有效。 如果两个颜色点是相等的，它们必须具有相同的坐标，因此也已保证它们的散列码是相等的。

以类 ColoredPoint 本身为例，equals的定义看起来没问题。但，一旦普通点和颜色点混合着一起时，equals的约定就将被破坏。 例如：

 Point p =  new    Point( 1  ,  2  );

 ColoredPoint cp =  new    ColoredPoint( 1  ,  2  , Color.RED);

 System.out.println(p.equals(cp));  // 输出 true

 System.out.println(cp.equals(p));  // 输出 false

相等比较“pequalscp”将调用 p 的equals方法，已在类 Point 中定义。该方法仅考虑两个点的坐标。因此，相等比较输出 true 值。而另一方面，相等比较“cp equals p”调用 cp 的 equals 方法，其中类 ColoredPoint 中已定义。该方法返回 false，因为 p 不是 ColoredPoint。该方法返回 false，因为 p 不是 ColoredPoint。 因此，equals定义的关系不是对称的。

对称的缺失将为集合造成意想不到的后果。下面为一个示例：

 Set< Point> hashSet1 =  new    java.util.HashSet< Point>();
 hashSet1.add(p);
 System.out.println(hashSet1.contains(cp));  // 输出 false

 Set< Point> hashSet2 =  new    java.util.HashSet< Point>();
 hashSet2.add(cp);
 System.out.println(hashSet2.contains(p));  // 输出 true

因此，即使 p 和 cp 是相等的，一个 contains 测试成功，而另一个却失败。

如何更改equals的 定义可以让它变为对称？基本上有两种方式。您可以使关系更一般或更严格。使它更加一般意味着对两个对象，a 和 b 被认为是相等的，如果比较 a 和 b 或 b 和 a 输出 true。以下为完成该功能的代码：

 public     class    ColoredPoint  extends    Point {  // 有问题：equals 不具有传递性

   private     final    Color color;

   public    ColoredPoint( int    x,  int    y, Color color) {
   super   (x, y);
   this   .color = color;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    ColoredPoint) {
  ColoredPoint that = (ColoredPoint) other;
  result = ( this   .color.equals(that.color) &&  super   .equals(that));
  }
   else     if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = that.equals( this   );
  }
   return    result;
  }
 }

在 ColoredPoint 中，equals的新定义比旧版本多了一种情况的检查：如果其他对象是 Point 而不是 ColoredPoint，该方法将使用 Point 的equals方法。这样就可以取得预期的效果，使equals具有对称性。现在，“cp.equals(p)”和“p.equals(cp)”都返回 true。 然而，equals的约定还是被打破了。现在的问题是，新的关系不再具有传递性！为了演示这个问题，下面进行一系列的声明。定义一个点和两个不同色的颜色 点，所有点在同一位置：

 ColoredPoint redP =  new    ColoredPoint( 1  ,  2  , Color.RED);
 ColoredPoint blueP =  new    ColoredPoint( 1  ,  2  , Color.BLUE);

单独来看，redp 等于 p 并且 p 等于 bluep：

 System.out.println(redP.equals(p));  // 输出 true

 System.out.println(p.equals(blueP));  // 输出 true

然而，比较 redP 和 blueP，输出 false：

 System.out.println(redP.equals(blueP));  // 输出 false

因此，这违反了equals约定中的传递性子条款。

让equals关系更一般看来是死路一条。下面我们试试让它更严格。使equals更严格的一个方法是：不同类的对象，不同地对待。通过修改类 Point 和 ColoredPoint 中的equals方法来实现。 在类 Point 中，可以添加一个额外的比较，用于检查其他点的运行时类是否与这个点的类相同，代码如下：

 // 技术上有效，但仍不能令人满意的 equals 方法
 public     class    Point {

   private     final     int    x;
   private     final     int    y;

   public    Point( int    x,  int    y) {
   this   .x = x;
   this   .y = y;
  }

   public     int    getX() {
   return    x;
  }

   public     int    getY() {
   return    y;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = ( this   .getX() == that.getX() &&  this   .getY() == that.getY()
  &&  this   .getClass().equals(that.getClass()));
  }
   return    result;
  }

   @Override    public     int    hashCode() {
   return    ( 41   * ( 41   + getX()) + getY());
  }
 }

然后，你就可以将类 ColoredPoint 的实现恢复为之前违反了对称性要求的版本：

 public     class    ColoredPoint  extends    Point {  // 不再违反平衡性要求

   private     final    Color color;

   public    ColoredPoint( int    x,  int    y, Color color) {
   super   (x, y);
   this   .color = color;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    ColoredPoint) {
  ColoredPoint that = (ColoredPoint) other;
  result = ( this   .color.equals(that.color) &&  super   .equals(that));
  }
   return    result;
  }
 }

在这里，类 Point 的实例被认为与系统类的其他实例是相等的，仅当对象具有相同的坐标，并且具有相同的运行时类，即每个对象 .getClass() 返回相同的值。 新的定义可以满足对象性和传递性的要求，因为现在对不同类之间的每次对比都将返回 false。因此，颜色点永远不会与普通点相等。这种约定看起来是合理的，当有人会指出新的定义太过严格了。

下面使用稍微有点绕的方式定义位于坐标(1, 2)上的点：

 Point pAnon =  new    Point( 1  ,  1  ) {
   @Override    public     int    getY() {
   return     2  ;
  }
 };

pAnon 等于 p 吗？答案是否定的，因为与 p 和 pAnon 关联的 java.lang.Class 对象是不同的。对于 p 是 Point 类，而对于 pAnon，它是 Point 的一个匿名子类。 但显然，pAnon 只是位于坐标(1, 2)上的另一个点。 认为它与 p 不同，看起来并不合理。

明智的方式：canEqual 方法

从以上各种情况，看起来我们进退两难。是否存在一种明智的方式，在类层次结构的多个分层中对等值比较进行重定义，而同时满足其约定？事实上，有这样 一种方式，但它需要另一个方法来重定义equals和 hashCode。这个想法是，只要类重定义 equals（和 hashCode），它就应该同时显式地声明，该类的所有对象与使用不同等值方法的超类中的对象，绝对不会相等。通过对重定义equals的每个类添加方 法 canEqual 就可以实现。以下为该方法的原型：

 public     boolean    canEqual(Object other)

当其他（other）对象是（重）定义了 canEqual 的类的实例时，该方法应返回 true，或者返回 false。它从equals中调用，以确保这些对象使用2种方式都是可比较的。下面是类 Point 新的也是最后的一个实现：

 public     class    Point {

   private     final     int    x;
   private     final     int    y;

   public    Point( int    x,  int    y) {
   this   .x = x;
   this   .y = y;
  }

   public     int    getX() {
   return    x;
  }

   public     int    getY() {
   return    y;
  }

   @Override    public     boolean    equals(Object other) {
   boolean    result =  false   ;
   if    (other  instanceof    Point) {
  Point that = (Point) other;
  result = (that.canEqual( this   ) &&  this   .getX() == that.getX() &&  this   .getY() == that.getY());
  }
   return