【第10条】请遵守通用约定覆盖equals

覆盖equals时请遵守通用约定

覆盖 equals 方法看起来似乎很简单，但是有许多覆盖方式会导致错误，并且后果非常严重 最容易避免这类问题的办法就是不覆盖 equals 方法，在这种情况下，类的每个实例都只与 自身相等 如果满足了以下任何一个条件，这就正是所期望的结果：

• 类的每个实例本质上都是唯一的。 对于代表活动实体而不是值（value）的类来说确实如 ，例如 Thread。Object 提供的 equals 实现对于这些类来说正是正确的行为。
• 类没有必要提供“逻辑相等”（ logical equality ）的测试功能。 例如， java.util.regex.Pattern 可以覆盖 equals ，以检查两个 Pattern 实例是否代表同一个正则表达式，但是设计者并不认为客户需要或者期望这样的功能。在这类情况之下，从Object 继承得到的 equals 实现已经足够了。
• 超类已经覆盖 equals，超类的行为对于这个类也是合适的 例如，大多数的Set 实现都从 Abstract Set 继承 equals 实现， List 实现从 AbstractListequals继承实现， Map 实现从 AbstractMap 继承 equals 实现
• 类是私有的，或者是包级私有的 可以确定它的 equals 方法永远不会被调用。如果你非常想要规避风险，可以覆盖 equals 方法，以确保它不会被意外调用：

@Override
public boolean equals(Object o) {
    throw new AssertionError(); // Method is never called
}

那么，什么时候应该覆盖equals方法呢？如果类具有自己特有的“逻辑相等”(logical equality)概念(不同于对象等同的概念)，而且超类还没有覆盖equals。这通常属于“值 类”(value class)的情形。值类仅仅是一个表示值的类，例如Integer或者String。程 序员在利用equals方法来比较值对象的引用时，希望知道它们在逻辑上是否相等，而不 是想了解它们是否指向同一个对象。为了满足程序员的要求，不仅必须覆盖equals方法, 而且这样做也使得这个类的实例可以被用作映射表(map)的键(key),或者集合(set)的元 素，使映射或者集合表现出预期的行为。

有一种“值类”不需要覆盖equals方法，即用实例受控(详见第1条)确保“每个 值至多只存在一个对象”的类。枚举类型(详见第34条)就属于这种类。对于这样的类而 言，逻辑相同与对象等同是一回事，因此Object的equals方法等同于逻辑意义上的 equals 方法。

在覆盖equals方法的时候，必须要遵守它的通用约定。下面是约定的内容，来自 Object的规范。equals方法实现了等价关系(equivalence relation),其属性如下：

• 自反性(reflexive)：对于任何非null的引用值x, x.equals (x)必须返回true。
• 对称性(symmetric)：对于任何非null的引用值x和y,当且仅当y.equals (x)返 回 true 时，x.equals(y)必须返回 true。
• 传递性(transitive)：对于任何非null的引用值x、y和z,如果x.equals (y)返回 true,并且 y. equals (z)也返回 true, x . equals (z)也必须返回 true。
• 一致性(consistent):对于任何非null的引用值x和y,只要equals的比较操作 在对象中所用的信息没有被修改，多次调用x.equals (y)就会一致地返回true, 或者一致地返回falseo
• 对于任何非null的引用值x, x.equals (null)必须返回false。
  除非你对数学特别感兴趣，否则这些规定看起来可能有点让人感到恐惧，但是绝对不要忽视这些规定！如果违反了，就会发现程序将会表现得不正常，甚至崩溃，而且很难找到 失败的根源。用John Donne的话说，没有哪个类是孤立的。一个类的实例通常会被频繁地 传递给另一个类的实例。有许多类，包括所有的集合类(collection class)在内，都依赖于传 递给它们的对象是否遵守了 equals约定。

现在你已经知道了违反equals约定有多么可怕，下面将更细致地讨论这些约定。值得欣慰的是，这些约定虽然看起来很吓人，实际上并不十分复杂。一旦理解了这些约定，要遵守它们并不困难。

那么什么是等价关系呢？不严格地说，它是一个操作符，将一组元素划分到其元素与另一个元素等价的分组中。这些分组被称作等价类(equivalence class)。从用户的角度来看， 对于有用的equals方法，每个等价类中的所有元素都必须是可交换的。现在我们按照顺 序逐一查看以下5个要求。

自反性(Reflexivity)：第一个要求仅仅说明对象必须等于其自身。很难想象会无意识 地违反这一条。假如违背了这一条，然后把该类的实例添加到集合中，该集合的contains方法将果断地告诉你，该集合不包含你刚刚添加的实例。

对称性(Symmetry)：第二个要求是说，任何两个对象对于“它们是否相等”的问题都必须保持一致。与第一个要求不同，若无意中违反这一条，这种情形倒是不难想象。例如下面的类，它实现了一个区分大小写的字符串。字符串由toString保存，但在equals 操作中被忽略。

import java.util.Objects;
public final class CaseInsensitiveString {
    private final String s;
    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }
    // Broken - violates symmetry!
    @Override
    public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString)
            return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
        if (o instanceof String) // One-way interoperability!
            return s.equalsIgnoreCase((String) o);
        return false;
    }
    ...// Remainder omitted
}

在这个类中，equals方法的意图非常好，它企图与普通的字符串对象进行互操作。假设我们有一个不区分大小写的字符串和一个普通的字符串：

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";

不出所料,cis.equals(s)返回trueo 问题在于，虽然CaseInsensitiveString类中的equals方法知道普通的字符串对象，但是，String类中的equals方法却并不知道不区分大小写的字符串。因此，s.equals(cis)返回false,显然违反了对称性。 假设你把不区分大小写的字符串对象放到一个集合中：

List<CaseInsensitiveString> list = new ArrayList<>();
list.add(cis);

此时list.contains(s)会返回什么结果呢？没人知道。在当前的OpenJDK实现 中，它碰巧返回false,但这只是这个特定实现得出的结果而已。在其他的实现中，它有可能返回true,或者抛出一个运行时异常。一旦违反了equals约定，当其他对象面对你的对象时，你完全不知道这些对象的行为会怎么样。

为了解决这个问题，只需把企图与String互操作的这段代码从equals方法中去掉就可以了。这样做之后，就可以重构该方法，使它变成一条单独的返回语句：

@Override
public boolean equals(Object o) {
    return o instanceof CaseInsensitiveString &&
        ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}

传递性(Transitivity)：equals约定的第三个要求是，如果一个对象等于第二个对象，而第二个对象又等于第三个对象，则第一个对象一定等于第三个对象。同样地，无意识地违反这条规则的情形也不难想象。用子类举个例子。假设它将一个新的值组件(value component)添加到了超类中。换句话说，子类增加的信息会影响equals的比较结果。我们首先以一个简单的不可变的二维整数型Point类作为开始：

public class Point {
    private final int x;
    private final int y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    @Override
    public boolean equals(Object o) {
       if (!(o instanceof Point))
           return false;
       Point p = (Point) o;
       return p.x == x && p.y == y;
   }
   ... // Remainder omitted
}

假设你想要扩展这个类，为一个点添加颜色信息：

public class ColorPoint extends Point {
    private final Color color;
    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }
    ... // Remainder omitted
}

equals方法会是什么样的呢？如果完全不提供equals方法，而是直接从Point继承过来，在equals做比较的时候颜色信息就被忽略掉了。虽然这样做不会违反equals约定，但很明显这是无法接受的。假设编写了一个equals方法，只有当它的参数是另一个有色点，并且具有同样的位置和颜色时，它才会返回true：

// Broken - violates symmetry!
@Override
public boolean equals(Object o) {
    if (!(o instanceof ColorPoint))
        return false;
    return super.equals(o) && ((ColorPoint) o).color == color;
}

这个方法的问题在于，在比较普通点和有色点，以及相反的情形时，可能会得到不同 的结果。前一种比较忽略了颜色信息，而后一种比较则总是返回false,因为参数的类型 不正确。为了直观地说明问题所在，我们创建一个普通点和一个有色点：

Point p = new Point(1, 2);
ColorPoint cp = new ColorPoint(1, 2, Color.RED);

然后，p.equals (cp)返回true, cp.equals §则返回false。你可以做这样 的尝试来修正这个问题，让ColorPoint.equals在进行“混合比较”时忽略颜色信息：

@Override
public boolean equals(Object o) {
    if (!(o instanceof Point))
        return false;
        
    // If o is a normal Point, do a color-blind comparison
    if (!(o instanceof ColorPoint))
        return o.equals(this);
        
    // o is a ColorPoint; do a full comparison
    return super.equals(o) && ((ColorPoint) o).color == color;
}

这种方法确实提供了对称性，但是丧失了传递性：

ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);

现此时,pl.equals(p2)和 p2.equals(p3)者返回 true, 但是 pl.equals(p3) 则返回false,很显然这违反了传递性。前两种比较不考虑颜色信息(“色盲”)，而第三种比较则考虑了颜色信息。

此外，这种方法还可能导致无限递归问题：假设Point有两个子类，如ColorPoint和SmellPoint,它们各自都带有这种equals方法。那么对myColorPoint.equals(mySmellPoint)的调用将会抛出 StackOverflowError 异常。

那该怎么解决呢？事实上，这是面向对象语言中关于等价关系的一个基本问题。我们无法在扩展可实例化的类的同时，既增加新的值组件，同时又保留equals约定，除非愿 意放弃面向对象的抽象所带来的优势。

你可能听说过，在equals方法中用getClass测试代替instanceof测试，可以 扩展可实例化的类和增加新的值组件，同时保留equals约定：

@Override
public boolean equals(Object o) {
    if (o == null || o.getClass() != getClass())
        return false;
    Point p = (Point) o;
    return p.x == x && p.y == y;
}

这段程序只有当对象具有相同的实现类时，才能使对象等同。虽然这样也不算太糟糕,但结果却是无法接受的：Point子类的实例仍然是一个Point,它仍然需要发挥作用，但是如果采用了这种方法，它就无法完成任务！假设我们要编写一个方法，以检验某个点是否处在单位圆中。下面是可以釆用的其中一种方法：

private static final Set<Point> unitCircle = Set.of(
    new Point( 1, 0), new Point( 0, 1),
    new Point(-1, 0), new Point( 0, -1));
    
public static boolean onUnitCircle(Point p) {
    return unitCircle.contains(p);
}

虽然这可能不是实现这种功能的最快方式，不过它的效果很好。但是假设你通过某种 不添加值组件的方式扩展了 Point,例如让它的构造器记录创建了多少个实例：

public class CounterPoint extends Point {
    private static final AtomicInteger counter =
        new AtomicInteger();
    public CounterPoint(int x, int y) {
        super(x, y);
        counter.incrementAndGet();
    }
    public static int numberCreated() {
        return counter.get();
   }
}

里氏替换原则(Liskov substitution principle)认为，一个类型的任何重要属性也将适用于它的子类型，因此为该类型编写的任何方法，在它的子类型上也应该同样运行得很好。针对上述Point的子类(如CounterPoint)仍然是Point,并且必须发挥作用的例子，这个就是它的正式语句。但是假设我们将CounterPoint实例传给了onUnitCircle方法。如果Point类使用了基于getClass的equals方法，无论CounterPoint实例的x和y值是什么，onUnitCircle方法都会返回false.这是因为像onUnitCircle方法所用的HashSet这样的集合，利用equals方法检验包含条件，没有任何CounterPoint实例与任何Point对应。但是，如果在Point ±使用适当的基于instanceof的equals方 法，当遇到CounterPoint时，相同的onUnitCircle方法就会工作得很好。

虽然没有一种令人满意的办法可以既扩展不可实例化的类，又增加值组件，但还是有 一种不错的权宜之计：遵从第18条“复合优先于继承”的建议。我们不再让ColorPoint 扩展Point,而是在ColorPoint中加入一个私有的Point域，以及一个公有的视图 (view)方法(详见第6条)，此方法返回一个与该有色点处在相同位置的普通Point对象：

// Adds a value component without violating the equals contract
public class ColorPoint {
    private final Point point;
    private final Color color;
    public ColorPoint(int x, int y, Color color) {
        point = new Point(x, y);
        this.color = Objects.requireNonNull(color);
    }
    /**
    * Returns the point-view of this color point.
    */
    public Point asPoint() {
        return point;
    }
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        ColorPoint cp = (ColorPoint) o;
        return cp.point.equals(point) && cp.color.equals(color);
    }
    ... // Remainder omitted
}

在Java平台类库中，有一些类扩展了可实例化的类，并添加了新的值组件。例如, java.sql.Timestamp对 java.util.Date进行了扩展，并增加了 nanoseconds域。 Timestamp 的equals实现确实违反了对称性，如果Timestamp和Date对象用于同一个集合中，或者以其他方式被混合在一起，则会引起不正确的行为。Timestamp类有一个免责声明，告诫程序员不要混合使用Date和Timestamp对象。只要你不把它们混合在一起，就不会有麻烦，除此之外没有其他的措施可以防止你这么做，而且结果导致的错误将很难调试。Timestamp类的这种行为是个错误，不值得仿效。

注意，你可以在一个抽象(abstract)类的子类中增加新的值组件且不违反equals约 定。对于根据第23条的建议而得到的那种类层次结构来说，这一点非常重要。例如，你 可能有一个抽象的Shape类，它没有任何值组件，Circle子类添加了一个radius域， Rectangle子类添加了 length和width域。只要不可能直接创建超类的实例，前面所 述的种种问题就都不会发生。

―致性(Consistency)：equals约定的第四个要求是，如果两个对象相等，它们就必须始终保持相等，除非它们中有一个对象(或者两个都)被修改了。换句话说，可变对象在不同的时候可以与不同的对象相等，而不可变对象则不会这样。当你在写一个类的时候,应该仔细考虑它是否应该是不可变的(详见第17条)。如果认为它应该是不可变的，就必须 保证equals方法满足这样的限制条件：相等的对象永远相等，不相等的对象永远不相等。

无论类是否是不可变的，都不要使equals方法依赖于不可靠的资源。如果违反了这条禁令，要想满足一致性的要求就十分困难了。例如，java.net.URL的equals方法依赖于对URL中主机IP地址的比较。将一个主机名转变成IP地址可能需要访问网络，随着时间的推移，就不能确保会产生相同的结果，即有可能IP地址发生了改变。这样会导致URL equals方法违反equals约定，在实践中有可能引发一些问题。URL equals方法的行为是一个大错误并且不应被模仿。遗憾的是，因为兼容性的要求，这一行为无法被改变。为了避免发生这种问题，equals方法应该对驻留在内存中的对象执行确定性的计算。

非空性(Non-nullity)：最后一个要求没有正式名称，我姑且称它为“非空性”，意思 是指所有的对象都不能等于null。尽管很难想象在什么情况下。.equals (null)调用会 意外地返回true,但是意外抛出NullPointerException异常的情形却不难想象。通 用约定不允许抛出NullPointerException异常。许多类的equals方法都通过一个显 式的null测试来防止这种情况：

@Override
public boolean equals(Object o) {
    if (o == null)
        return false;
    ...
}

这项测试是不必要的。为了测试其参数的等同性，equals方法必须先把参数转换成适 当的类型，以便可以调用它的访问方法，或者访问它的域。在进行转换之前，equals方法 必须使用instanceof操作符，检查其参数的类型是否正确：

@Override
public boolean equals(Object o) {
    if (!(o instanceof MyType))
        return false;
    MyType mt = (MyType) o;
    ...
}

如果漏掉了这一步的类型检查，并且传递给equals方法的参数又是错误的类型，那么equals方法将会抛出ClassCastException异常，这就违反了 equals约定。但是，如果instanceof的第一个操作数为null,那么，不管第二个操作数是哪种类型， instanceof操作符都指定应该返回false。因此，如果把null传给 equals方法，类型检查就会返回false,所以不需要显式的null检査。

结合所有这些要求，得出了以下实现高质量equals方法的诀窍：

1. 使用==操作符检查“参数是否为这个对象的引用"。如果是，则返回true。这只 不过是一种性能优化，如果比较操作有可能很昂贵，就值得这么做。
2. 使用instanceof操作符检查“参数是否为正确的类型”。如果不是，则返回false。一般说来，所谓“正确的类型”是指equals方法所在的那个类。某些情况下，是指该类所实现的某个接口。如果类实现的接口改进了equals约定，允许在实现了该接口的类之间进行比较，那么就使用接口。集合接口如Set、List、Map和Map. Entry具有这样的特性。
3. 把参数转换成正确的类型。因为转换之前进行过instanceof测试，所以确保会成功。
4. 对于该类中的每个“关键"(significant)域，检查参数中的域是否与该对象中对应的域相匹配。如果这些测试全部成功，则返回true；否则返回false。如果第2步中的类型是个接口，就必须通过接口方法访问参数中的域；如果该类型是个类，也许就能够直接访问参数中的域，这要取决于它们的可访问性。
   对于既不是float也不是double类型的基本类型域，可以使用==操作符进行比较；对于对象引用域，可以递归地调用equals方法；对于float域，可以使用静态Float.compare(float, float)方法；对于 double域，则使用Double.compare(double, double)。对float和double域进行特殊的处理是有必要的，因为存在着Float.NaN、-0.Of以及类似的double常量；虽然可以用静态方法Float.equals和Double.equals对float和double域进行比较，但是每次比较都要进行自动装箱，这会导致性能下降。对于数组域，则要把以上这些指导原则应用到每一个元素上。如果数组域中的每个元素都很重要，就可以使用其中一个Arrays.equals方法。

有些对象引用域包含null可能是合法的，所以，为了避免可能导致NullPointerException异常，则使用静态方法Objects.equals(Object, Object)来检查这类域 的等同性。

对于有些类，比如前面提到的CaselnsensitiveString类，域的比较要比简单的等同性测试复杂得多。如果是这种情况，可能希望保存该域的一个“范式”(canonical form),这样equals方法就可以根据这些范式进行低开销的精确比较，而不是高开销的非精确比较。这种方法对于不可变类(详见第17条)是最为合适的；如果对象可能发生变化，就必须使其范式保持最新。

域的比较顺序可能会影响equals方法的性能。为了获得最佳的性能，应该最先比较 最有可能不一致的域，或者是开销最低的域，最理想的情况是两个条件同时满足的域。不应该比较那些不属于对象逻辑状态的域，例如用于同步操作的Lock域。也不需要比较衍生域 (derived field),因为这些域可以由“关键域”(significant field)计算获得，但是这样做有可能提高equals方法的性能。如果衍生域代表了整个对象的综合描述，比较这个域可以节省在比较失败时去比较实际数据所需要的开销。例如，假设有一个Polygon类，并缓存了该面积。如果两个多边形有着不同的面积，就没有必要去比较它们的边和顶点。

在编写完equals方法之后，应该问自己三个问题：它是否是对称的、传递的、一致的？并且不要只是自问，还要编写单元测试来检验这些特性，除非用AutoValue(后面会讲到)生成equals方法，在这种情况下就可以放心地省略测试。如果答案是否定的，就要找出原因，再相应地修改 equals 方法的代码 当然， equals 方法也必须满足其他两个特性（自反性和非空性），但是这两种特性通常会自动满足。

根据上面的诀窍构建 equals 方法的具体例子，请看下面这个简单的 PhoneNurnber 类：

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;
    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "area code");
        this.prefix = rangeCheck(prefix, 999, "prefix");
        this.lineNum = rangeCheck(lineNum, 9999, "line num");
    }
    private static short rangeCheck(int val, int max, String arg) {
        if (val < 0 || val > max)
           throw new IllegalArgumentException(arg + ": " + val);
       return (short) val;
   }
   @Override
   public boolean equals(Object o) {
       if (o == this)
           return true;
       if (!(o instanceof PhoneNumber))
           return false;
       PhoneNumber pn = (PhoneNumber) o;
       return pn.lineNum == lineNum && pn.prefix == prefix
               && pn.areaCode == areaCode;
   }
   ... // Remainder omitted
}

下面是最后的一些告诫：

1. 覆盖equals时总要覆盖hashCode (详见第11条)。
2. 不要企图让equals方法过于智能。如果只是简单地测试域中的值是否相等，则不难做到遵守equals约定。如果想过度地去寻求各种等价关系，则很容易陷入麻烦之中。把任何一种别名形式考虑到等价的范围内，往往不会是个好主意。例如，File类不应该试图把指向同一个文件的符号链接(symbolic link)当作相等的对象来看待。所幸File类没有这样做。
3. 不要将equals声明中的Object对象替换为其他的类型。程序员编写出下面这样的equals方法并不鲜见，这会使程序员花上数个小时都搞不清为什么它不能正常工作：

// Broken - parameter type must be Object!
public boolean equals(MyClass o) {
    …
}

问题在于，这个方法并没有覆盖(override) Object.equals ,因为它的参数应该是Object类型，相反，它重载(overload)了 Object.equals (详见第52条)。在正常equals方法的基础上，再提供一个“强类型”(strongly typed)的equals方法，这是无法接受的，因为会导致子类中的Override注解产生错误的正值，带来错误的安全感。

// Still broken, but won’t compile
@Override
public boolean equals(MyClass o) {
    …
}

编写和测试equals(及hashCode)方法都是十分烦琐的，得到的代码也很琐碎。代替手工编写和测试这些方法的最佳途径，是使用Google开源的AutoValue框架，它会自动替你生成这些方法，通过类中的单个注解就能触发。在大多数情况下，AutoValue生成的方法本质上与你亲自编写的方法是一样的。

IDE也有工具可以生成equals和hashCode方法，但得到的源代码比使用AutoValue的更加冗长，可读性也更差，它无法自动追踪类中的变化，因此需要进行测试。也就是说，让IDE生成equals(及hashCode)方法，通常优于手工实现它们，因为IDE不会犯粗心的错误，但是程序员会犯错。

总而言之，不要轻易覆盖equals方法，除非迫不得已。因为在许多情况下，从Object处继承的实现正是你想要的。如果覆盖equals, 一定要比较这个类的所有关键域，并且查看它们是否遵守equals合约的所有五个条款。