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 方法时遇到的那些"小坑"和解决方案！
