如何正确重写equals方法判断对象相等

正确重写 `equals` 方法远不止是简单比较字段，它是一套必须与 `hashCode` 严格协同、遵循自反性/对称性/传递性/一致性契约的精密操作：签名必须为 `public boolean equals(Object obj)`，首行检查引用相等并防御空指针和类型不匹配，字段比较需按类型选用 `==`、`Objects.equals` 或 `Arrays.equals`，所有参与 `equals` 的字段必须无一遗漏地纳入 `hashCode` 计算——否则在 `HashMap`、`HashSet` 中将遭遇“明明相等却查不到”或“重复添加”的诡异故障；更隐蔽的风险在于继承设计、浮点数比较、可变字段修改导致的集合失效，而这些错误往往上线后才爆发，极难排查。

重写 equals 前必须先重写 hashCode

Java 中如果只重写 equals 而不重写 hashCode，会导致对象在 HashMap、HashSet 等集合中行为异常：两个逻辑相等的对象可能被散列到不同桶里，从而查不到、重复添加。

• 违反 Object.hashCode 合约：相等的对象必须有相同哈希值
• 常见错误现象：set.contains(obj) 返回 false，尽管 obj.equals(existing) 是 true
• IDE（如 IntelliJ）生成的 equals 通常会同步生成 hashCode，但手动写时极易漏掉
• 若字段参与 equals 比较，就必须参与 hashCode 计算——哪怕只是简单相加或用 Objects.hash(...)

equals 方法签名和空值检查不能错

签名必须是 public boolean equals(Object obj)，少一个 Object 类型参数，或写成 equals(MyClass other)，就不是重写而是重载，运行时根本不会调用你写的版本。

• 第一行必须做 if (this == obj) return true;：处理自反性，也避免后续空指针
• 紧接着 if (obj == null || getClass() != obj.getClass()) return false;：既防 NullPointerException，又保证类型严格一致（用 getClass() 而非 instanceof，除非你明确支持子类对等）
• 错误示例：if (obj instanceof MyClass) 在继承场景下可能破坏对称性，比如 SubClass.equals(MyClass) 为 true，但反过来不成立

字段比较要区分基本类型、引用类型和 null 安全

字段逐个比较时，不能直接用 == 或 .equals() 一概而论，否则会触发空指针或误判。

• 基本类型（int、boolean 等）用 ==
• 引用类型（包括包装类、String、自定义对象）统一用 Objects.equals(field1, field2)：它内部已处理任一参数为 null 的情况
• 数组字段要用 Arrays.equals(arr1, arr2)，而不是 .equals()（那是引用比较）
• 忽略某些字段？可以，但得有明确业务理由（比如时间戳、ID 自动生成字段），并在文档里说明“该字段不影响逻辑相等性”

别忘了测试对称性、传递性和一致性

这些不是理论要求，而是真实踩坑点。JVM 不校验，但业务出错时很难定位。

• 对称性失败典型场景：用了 instanceof + 子类，或一方字段多做了非空校验另一方没做
• 传递性问题常出现在浮点数比较（没用 Double.compare）、或嵌套对象的 equals 实现不一致
• 一致性要求：只要参与比较的字段没变，多次调用 equals 必须返回相同结果。所以别在 equals 里读数据库、改状态、或依赖随机/时间等可变值
• 建议写几个最小单元测试：互换参数顺序、加入 null、构造两个仅一个字段不同的实例，观察是否符合预期

最容易被忽略的是：当类被用作 Map 的 key 或放入 Set 后，再修改影响 equals 判断的字段——这会让集合内部结构失效，且没有任何警告。

终于介绍完啦！小伙伴们，这篇关于《如何正确重写equals方法判断对象相等》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！