java重写equals必须严格满足五项契约：自反性（x.equals(x)为true）、对称性（x.equals(y)⇔y.equals(x)）、传递性（x=y且y=z⇒x=z）、一致性（结果不随时间变化）、非空性（对null返回false），且必须同步重写hashcode，二者所用字段须完全一致。
Java 中重写 equals 方法，不是“加个判断就行”，而是必须严格满足五项契约：自反性、对称性、传递性、一致性、非空性。这些不是理论要求，而是 JVM 集合框架（如 HashSet、HashMap、ArrayList.contains()）正常工作的底层前提。
自反性：自己必须等于自己
任何非 null 对象调用 x.equals(x) 必须返回 true。违反它会导致集合查找失败——比如把对象加入 ArrayList 后，再调用 list.contains(x) 却返回 false。
- 常见错误：在比较字符串时用了
obj.getName().trim().equals(this.name.trim())，但没对this.name做同样处理，导致this.equals(this)返回false - 安全写法：统一使用
Objects.equals(this.name, other.name)，它自动处理 null 和自反场景 - 最简保障：开头加
if (this == obj) return true;，直接拦截引用相等的情况
对称性：x 等于 y，y 就必须等于 x
若 x.equals(y) == true，则 y.equals(x) 也必须为 true。破坏对称性最典型后果是 HashMap 的 key 找不到，或 Set 重复添加。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 高频陷阱：用
instanceof判断类型，父类允许和子类比较，但子类不接受父类（因instanceof Parent对子类实例返回true，而instanceof Child对父类实例返回false） - 推荐做法：用
getClass() == obj.getClass()替代instanceof，确保类型完全一致 - 更优解：避免在可继承的父类中重写
equals；改用record类或组合方式，天然规避跨类型比较问题
传递性：链条不能断
若 x.equals(y) 且 y.equals(z) 都为 true，则 x.equals(z) 也必须为 true。这是最容易被忽略却危害最大的一条。
- 经典翻车：父类
Person按name判等，子类Student加了id并扩展equals，结果出现p1.equals(s1) → true、s1.equals(s2) → false、p1.equals(s2) → true，破坏传递链 - 根本解法：不在父子类中分别重写
equals；要么只在最终具体类中实现，要么用record或不可变值类统一管理 - 如果必须支持继承，应设计成“仅通过公共字段比较”，且所有子类都遵循同一套字段集
一致性：只要数据没变，结果就不变
只要参与比较的字段未被修改，多次调用 x.equals(y) 必须返回相同结果。它防止集合行为随时间漂移，比如 HashMap 在扩容后找不到原 key。
- 风险操作：在
equals中依赖外部状态（如当前时间、随机数、IO 结果）或可变字段（如未加final的计算缓存） - 正确做法：只基于对象的稳定字段（
final或业务上不可变的属性）比较 - 注意：若字段本身是对象（如
List），需确保其内容也不变，或使用不可变容器（如ImmutableList）
别忘了同步重写 hashCode
equals 和 hashCode 是一对契约：如果两个对象 equals 返回 true，它们的 hashCode 必须相等。否则 HashMap、HashSet 会直接失效。
- 生成方式：可用
Objects.hash(field1, field2, ...)，简洁且自动处理 null - 字段一致性：
hashCode计算所用字段，必须和equals中参与比较的字段完全一致 - 不变性要求：同
equals，hashCode也应基于不可变字段，避免哈希桶错位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
