17370845950

只重写equals会导致HashSet找不到对象，因为HashSet先用hashCode定位桶再用equals比对；若逻辑相等的对象哈希值不同，就会散列到不同桶中，造成contains返回false、add重复对象成功等现象。

为什么只重写 equals 会导致 HashSet 找不到对象？

因为 HashSet（以及 HashMap）先用 hashCode 定位桶，再用 equals 精确比对。如果两个逻辑相等的对象（u1.equals(u2) == true）返回不同哈希值，它们大概率被散列到不同桶里——set.contains(u2) 就会返回 false，哪怕 u1 已在集合中。

• 现象：对象内容一样，contains 返回 false；add 同一对象两次，集合大小变成 2
• 根本原因：hashCode 仍走 Object 默认实现（基于内存地址），而 equals 已按业务字段比较
• 不是“偶尔出错”，而是“必然失效”——只要哈希值不一致，哈希集合的查找逻辑就断了

equals 和 hashCode 的契约到底约束什么？

Java 规范只强制一条核心规则：如果 a.equals(b) == true，那么 a.hashCode() == b.hashCode() 必须为 true。反过来不成立（哈希相同 ≠ 一定相等）。

• 违反该契约 → HashMap.get(key) 可能返回 null，即使键确实存在
• 自反性、对称性等是 equals 自身要求，但若没同步更新 hashCode，这些也白搭
• 别用 getClass() != obj.getClass() 做类型检查（影响继承），改用 instanceof 更安全

怎么写才不算翻车？三个实操底线

别自己手算哈希或拼字符串，用 JDK 提供的工具链保底。

• equals 中只比较「不可变」或「参与业务判等」的字段，比如 id 或 name，别把 lastLoginTime 这种可变字段塞进去
• hashCode 必须用和 equals 完全相同的字段计算，推荐 Objects.hash(id, name) ——它自动处理 null，且结果确定
• 一旦对象进了 HashSet 或当了 HashMap 的 key，就别再修改参与 hashCode 计算的字段，否则永远找不回来

IDE 自动生成的代码为什么有时还出问题？

IntelliJ 或 Eclipse 生成的 equals/hashCode 大多合规，但容易忽略两个隐形坑：

• 选错了参与比较的字段：比如勾了 createTime，但业务上只认 id，结果时间戳微差就判不等
• 用了 getClass() 严格类型检查，导致子类对象无法和父类实例 equals（比如 AdminUser 和 User）
• 字段是懒加载的代理对象（如 Hibernate 的 LazyInitializationException 场景），getter 可能抛异常 —— 此时应改

  

  用字段直取或加空判断

真正难的从来不是“怎么写”，而是“哪些字段该进判等逻辑”，这得抠清楚业务语义，而不是堆代码。