重写 equals 时必须同时重写 hashCode，这是 Java 集合框架正常运行的硬性要求；二者须基于相同非可变字段计算，否则会导致哈希结构中对象“消失”、重复添加、查找失败等线上故障。

重写 equals 时必须同时重写 hashCode，不是约定俗成的“建议”，而是 Java 集合框架正常运转的硬性要求。核心在于：哈希结构（如 HashMap、HashSet）依赖二者协同工作——先用 hashCode 快速定位桶（bucket），再用 equals 精确比对内容。若只改一个，逻辑就断了。

为什么 hashCode 不匹配会导致对象“消失”

假设你只重写了 equals，让两个 ID 相同的 User 对象视为相等，但没重写 hashCode：

• 它们的 hashCode 仍由默认实现返回（基于内存地址），大概率不同
• 放入 HashSet 时，会被散列到不同桶中 → 集合认为是两个不同元素
• 用 contains() 查找时，会去错的桶里调用 equals → 找不到明明“相等”的对象
• 结果就是：重复添加、查不到、remove 失败、缓存命中率暴跌

Java 官方明确规定的契约关系

这个规则写在 Object.hashCode() 的 Javadoc 里，是强制契约：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 正向保证：如果 a.equals(b) == true，那么 a.hashCode() == b.hashCode() 必须成立
• 逆否有效：如果 a.hashCode() != b.hashCode()，那 a.equals(b) 一定为 false
• 不反推：hashCode 相同 ≠ equals 为 true（允许哈希冲突，靠 equals 善后）

怎么写才合规：关键操作要点

二者必须基于同一组字段计算，且逻辑完全一致：

立即学习“Java免费学习笔记（深入）”；

• 选字段：只用参与 equals 判断的非可变字段（如 id、name；避免用 lastLoginTime 这类会变的）
• 用 Objects.equals() 和 Objects.hash()，它们自动处理 null 安全和类型一致性
• 示例片段：

  @Override
  public boolean equals(Object o) {
      if (this == o) return true;
      if (o == null || getClass() != o.getClass()) return false;
      User user = (User) o;
      return Objects.equals(id, user.id) && Objects.equals(name, user.name);
  }
  
  @Override
  public int hashCode() {
      return Objects.hash(id, name); // 字段顺序、数量、是否为null，必须和 equals 完全对应
  }

不遵守的典型后果场景

这些不是理论风险，而是线上高频故障：

• HashMap<User, Order> 中，相同用户反复 put，却生成多个键 → 订单数据分散、统计不准
• HashSet<Product> 无法去重，购物车出现重复商品
• JPA 实体作为 Map 键时，二级缓存失效或错乱
• Lombok 的 @EqualsAndHashCode 自动生成时，若漏掉字段或加了可变字段，同样破约