theme: cyanosis

今天想和大家聊聊 Java 中的 equals 方法。其实，很多人刚接触 Java 的时候，对 equals 的理解可能还停留在"这个方法就是比较对象是否相等"的层面，但深入源码之后你会发现，这个看似简单的方法背后其实蕴藏着不少设计智慧和细节。

Object 类中 equals 的默认实现

所有的 Java 类都是从 Object 类继承而来，而 Object 类中的 equals 方法默认实现非常简单：

public boolean equals(Object obj) {

return (this == obj);

}

也就是说，默认情况下，equals 仅仅比较两个对象的引用是否相同，也就是它们在内存中的地址是否一致。这就意味着，即使两个对象的内容完全一样，只要它们不是同一个实例，equals 方法也会返回 false。这样的设计在很多场景下显然并不能满足我们对"相等"这一概念的直观理解。

String 类中的 equals 实现

为了满足实际开发中"内容相等"的需求，很多类都对 equals 方法进行了重写。最典型的例子就是 String 类。在 String 类中，equals 方法的实现逻辑大致可以分为以下几个步骤：

快速判断引用是否相同：首先判断 this 和传入的对象是否是同一个引用，如果是，就直接返回 true；

判断对象类型：如果引用不同，再判断传入的对象是否为 String 类型，不是的话直接返回 false；

比较字符串长度：两个字符串只有长度相同，才有可能内容相等；

逐个比较字符：最后通过遍历字符串内部存储字符的数组，逐个比较每个字符是否一致，只有全部字符都相等才返回 true。

这种实现不仅考虑了效率（比如先判断引用、类型和长度），更注重了"内容"这个维度，让我们在比较字符串是否相等时得到了预期的结果。

equals 方法的"合约"

除了 String 类，很多我们自定义的类也需要重写 equals 方法，这就引出了另一个很重要的点：equals 方法的"合约"。在重写 equals 方法时，我们需要确保它满足以下几个基本原则：

自反性：对于任何非 null 对象 x，x.equals(x) 必须返回 true。

对称性：如果 x.equals(y) 返回 true，那么 y.equals(x) 也必须返回 true。

传递性：如果 x.equals(y) 返回 true 且 y.equals(z) 返回 true，那么 x.equals(z) 也必须返回 true。

一致性：如果两个对象的信息没有发生改变，多次调用 x.equals(y) 应该始终返回同样的结果。

非空性：任何对象和 null 比较都应该返回 false。

equals 与 hashCode 的关系

实现好了 equals 方法后，还需要特别注意一个常见的坑：当你重写了 equals 方法时，通常也需要重写 hashCode 方法。因为在使用 HashMap、HashSet 等基于哈希的集合时，如果两个对象通过 equals 判断相等，它们的 hashCode 必须一致，否则很可能会出现数据丢失或者查找失败的情况。

instanceof 还是 getClass()?

再说说判断对象类型的问题。大家在重写 equals 方法时常常会遇到一个选择：到底是使用 instanceof 还是使用 getClass() 来判断对象的类型。

使用 instanceof 判断时，可以允许父子类之间的比较，但这有可能破坏对称性。举个例子，如果父类的 equals 方法允许比较子类对象，而子类的 equals 方法又有额外的判断条件，那么可能会出现 A.equals(B) 与 B.equals(A) 返回结果不一致的情况。

而使用 getClass() 判断时，则要求两个对象必须是完全相同的类，虽然这种方式更严格，但能确保对称性。

总结

总的来说，equals 方法虽然看起来只有几十行代码，但它在设计上要求非常严谨，需要考虑多个方面的问题。正确地重写 equals 方法，不仅能够提高代码的健壮性，也能避免在实际应用中出现各种意想不到的 bug。希望大家在实际开发中能够认真对待这一点，不断打磨自己的代码质量。加油，相信你一定能在 Java 的世界里越走越远～😄

欢迎大家留言讨论你在重写 equals 方法时遇到的那些"小坑"和解决方案！