建议：覆盖equals时请遵守通用约定。

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

• 类的每个实例本质上都是唯一的。对于代表活动实体而不是值（value）的类来说确实如此，例如Thread。Object提供的equals实现对于这些类来说正是正确的行为。

• 不关心类是否提供了“逻辑相等（logical equality）”的测试功能。例如，java.util.Random覆盖了equals，以检查两个Random实例是否产生相同的随机数序列，但是设计者并不认为客户需要或者期望这样的功能。在这样的情况下，从Object继承得到的equals实现已经足够了。

• 超类已经覆盖了equals，从超类继承过来的行为对于子类也是适合的。例如大多数的Set实现都从AbstractSet继承equals实现，List实现从AbstractList继承equals实现，Map实现从AbstractMap继承equals实现。

• 类是私有的或是包级私有的，可以确定它的equals方法永远不会被调用。在这种情况下，无疑是应该覆盖equals方法的，一方它被意外调用：

@Override

public boolean equals(Object o) {

throw new AssertionError(); // Method is neve called

}

那么，什么时候应该覆盖Object.equals呢？如果类具有自己特有的“逻辑相等”概念（不同于对象等同的概念），而且超类还没有覆盖equals以实现期望的行为，这时我们就需要覆盖equals方法。这通常属于“值类（value class）”的情形。值类仅仅是一个表示值得类，例如Integer或Date。

在覆盖equals方法的时候，你必须要遵守它的通用约定。下面是约定的内容，来自Object的规范【JavaSE6】：

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

• 对称性（symmetry）——第二个要求是说，任何两个对象对于“它们是否相等”的问题都必须保持一致。与第一个要求不同，若无意中违反这一条，这种情形倒是不难想象。

• 传递性（transitivity）——equals约定的第三个要求是，如果一个对象等于第二个对象，并且第二个对象又等于第三个对象，则第一个对象一定等于第三个对象。同样地，无意识地违反这条规则的情形也不难想象。考虑子类的情形，它将一个新的值组件（value component）添加到了超类中。换句话说，子类增加的信息会影响到equals的比较结果。

注意：我们无法在扩展可实例化的类的同时，既增加新的值组件，同时又保留equals约定，除非愿意放弃面向对象的抽象所带来的优势。

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

注意，你可以在一个抽象（abstract）类的子类中增加新的值组件，而不会违反equals约定。

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

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

• 非空性（Non-nullity）——最后一个要求是，指所有的对象都必须不等于null。尽管很难想象什么情况下o.equals(null)调用会意外地返回true，但是意外抛出NullPointerException异常的情形却不难想象。通过约定不允许抛出NullPointerException异常。

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

• 使用==操作符检查“参数是否为这个对象的引用”。如果是，则返回true，这只不过是一种性能优化，如果比较操作有可能很昂贵，就值得这么做。

• 使用instanceof操作符检查“参数是否为正确的类型”。如果不是，则返回false。一般说来，所谓“正确的类型”是指equals方法所在的那个类。有些情况下，是指该类所实现的某个接口。如果类实现的接口改进了equals约定，允许在实现了该接口的类之间进行比较，那么就使用接口。集合接口（collection interface）如Set、List、Map和Map.Entry具有这样的特性。

• 把参数转换成正确的类型。因为转换之前进行过instanceof测试，所以确保会成功。

• 对于该类中的每个“关键（significant）”域，检查参数中的域是否与该对象中对应的域相匹配。如果这些测试全部成功，则返回true；否则返回false。如果第2步中的类型是个借口，就必须通过接口方法访问参数中的域；如果该类型是个类，也许就能够直接访问参数中的域，这要取决于他们的可访问性。

对于既不是float也不是double类型的基本类型域，可以使用==操作符进行比较；对于对象引用域，可以递归地调用equals方法；对于float域，可以使用Float.compare方法；对于double域，则使用Double.compare。对float和double域进行特殊的处理是有必要的，因为存在着Float.NaN、-0.0f以及类似double常量；对于数组域，则要把以上这些指导原则应用到每个元素上。如果数组域中的每个元素都很重要，就可以使用发行版本1.5中新增的其中一个Arrays.equals方法。

有些对象引用域包含null可能是合法的，所以为了避免可能导致NullPointerException异常，则使用下面的习惯用法来比较这样的域：

(field == null ? o.field == null : field.equals(o.field))

如果field和o.field通常是相同的对象引用，那么下面的做法就会更快一些：

(field == null || (field != null && field.equals(o.field)))

对于这些类，域的比较要比简单的灯通行测试复杂得多。如果是这种情况，可能会希望保存该域的一个“范式（canonical form）”，这样equals方法就可以根据这些范式进行低开销的精确比较，而不是高开销的非精确比较。这种方法对于不可变类是最为合适的；如果对象可能发生变化，就必须使其范式保持最新。

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

• 当你编写完成了equals方法之后，反问自己三个问题：他是否是对称的、传递的、一致的？并且不要只是自问，还要编写单元测试来检验这些特性！如果答案是否定的，就要找出原因，再相应的修改equals方法的代码。当然，equals方法也必须满足其他两个特性（自反性和非空性），但是这两种特性通常会自动满足。

下面是最后的一些告诫：

• 覆盖equals时总要覆盖hashcode。

• 不要企图让equals方法过于智能。如果只是简单的测试域中的值是否相等，则不难做到遵守equals约定。如果想过度的去寻求各种等价关系，则很容易陷入麻烦之中。把任何一种别名形式考虑到等价的范围内，往往不会是好主意。例如，File类不应该试图把指向同一个文件的符号链接（symbolic link）当做相等的对象来看待。所幸File类没有这样做。

• 不要讲equals声明中的Object对象替换为其他的类型。