如何遵循自反性、对称性、传递性改写equals方法以维护集合正确性？

本文共计1089个文字，预计阅读时间需要5分钟。

集合类（例如 HashSet、ArrayList）内部使用 equals 方法来判断元素是否存在。如果对象的 equals 方法返回 false，那么即使 list.contains(x) 也可能返回 false。这是因为在集合中，默认的 equals 方法通常不会识别对象为自己，导致即使对象是集合的成员，也可能返回 false。

常见破环自反性的写法：

• 在字段比较前做了非空 trim 或 toLowerCase，但没对当前对象自身做同样处理（比如 this.name.trim().equalsIgnoreCase(other.name.trim())，而 this.name 本身含首尾空格，this.name.trim() 就和原始值不等了）
• 用了 instanceof 判类型后直接强转，却忘了先检查 this == obj

正确做法：开头加 if (this == obj) return true;，这是最廉价也最可靠的自反性保障。

对称性被破坏会让 HashMap 的 key 查不到

HashMap 在 get() 时会先用 key 的 hashCode() 定位桶，再用 equals() 确认是否命中。如果 a.equals(b) 是 true，但 b.equals(a) 是 false，那把 a 当 key 存进去后，用 b 去查就永远返回 null。

典型错误场景：

• 子类重写 equals 时用 instanceof Parent，父类却用 getClass() == obj.getClass() —— 导致父子互判不等
• 与 String 之类 JDK 类做“单向兼容”，比如 if (obj instanceof String) 分支里做忽略大小写的比较，但 String 自己的 equals 不会反过来认你

建议统一用 getClass() == obj.getClass() 做类型校验，避免继承带来的对称性风险；如需跨类型比较，必须双方约定且双向实现。

传递性失效会让 TreeSet 排序混乱甚至抛异常

TreeSet 和 TreeMap 依赖 equals 和 compareTo 的逻辑一致性。但即使只用 equals，传递性崩塌也会让集合行为不可预测。例如：p1.equals(p2) == true、p2.equals(p3) == true，但 p1.equals(p3) == false，这时往 HashSet 里 add 这三个对象，可能实际存进两个或三个，完全取决于插入顺序。

最容易踩坑的是字段参与比较时的“选择性忽略”：

• 只比业务主键（如 id），但 id 可能为 0 或 null，导致多个无 id 对象互相相等
• 在子类中额外比一个字段（如 status），但父类 equals 没包含它，造成 “A==B、B==C，但 A!=C”

解决思路：所有参与 equals 的字段，必须稳定、非临时、可重复读取；涉及继承时，要么全用 getClass() 锁死类型，要么用组合代替继承，避免字段集错层。

为什么同步重写 hashCode 是硬性前提

只要违反自反性/对称性/传递性中的任一条件，hashCode 很可能已经不一致了——因为 Objects.hash(...) 的输入字段和 equals 的字段不匹配，或者 hashCode 里用了可变字段（如 lazy-calculated 字段），而 equals 没用它。

关键点：

• hashCode 必须基于 equals 中**全部**用于判断相等的字段计算
• 如果 equals 里用了 Objects.equals(a, b)，hashCode 就得用 Objects.hash(a, b)，不能漏、不能多、不能换顺序
• 运行时修改了影响 equals 的字段，又没重新计算 hashCode，放进 HashSet 后就再也找不到了

真正容易被忽略的不是“要不要重写 hashCode”，而是字段变更后，对象是否还该留在原哈希桶里——这要求字段从设计之初就得是不可变的，或至少在加入集合后不再改动。