equals与hashCode为何要同时重写？

在Java中，`equals()`与`hashCode()`必须成对重写，否则看似逻辑相等的对象在HashMap、HashSet等哈希集合中会“消失”——因为哈希表先靠`hashCode()`定位桶，再用`equals()`精确匹配；若只重写`equals()`，相同内容的不同实例可能散列到不同桶，导致`get()`或`containsKey()`直接返回`false`，根本不会触发你的`equals()`判断。重写时既要确保相等对象哈希值一致、避免使用可变字段、妥善处理`null`安全，又要严格保持`equals()`与`hashCode()`所依赖的字段完全一致；借助`Objects.equals()`和`Objects.hash()`可大幅降低手写错误风险，而IDE生成或Lombok注解虽便捷，却极易因字段遗漏、继承未适配或可变状态引入隐性故障——一个缓存命中率归零的深夜告警，往往就源于某次只改了`equals()`却忘了同步更新`hashCode()`的微小疏忽。

为什么HashMap里不重写hashCode()会导致equals()失效

因为哈希表先靠hashCode()决定对象存哪条链（或哪个桶），再用equals()在该桶内逐个比对。如果只重写equals()，两个逻辑相等的对象可能被散列到不同桶里，get()或containsKey()直接找不到——根本没机会调用你的equals()。

• 常见错误现象：map.get(new Person("Alice", 25))返回null，尽管map.containsKey(new Person("Alice", 25))也返回false，但map里明明“有”这个key
• 本质是散列定位失败：默认Object.hashCode()返回内存地址，两个内容相同但不同实例的对象，hashCode()值不同 → 分配到不同桶
• 只要类会放进HashMap、HashSet或作为ConcurrentHashMap的key，就必须同时重写这两个方法

重写hashCode()时最容易错的三件事

不是“随便算个数就行”，得保证：相等的对象必须有相同的hashCode()；不等的对象尽量有不同hashCode()（减少碰撞）；且计算过程不能依赖可变字段。

• 用可变字段参与计算：比如把age字段加入hashCode()，之后改了age，对象在HashSet里的位置就“丢”了——再也找不回来
• 忽略null安全：字段可能为null，直接调field.hashCode()会抛NullPointerException；应改用Objects.hashCode(field)
• 只用部分字段：比如Person类中仅用name算hashCode()，但equals()比较name + age，就会违反“相等必同哈希”原则

Objects.equals()和Objects.hash()怎么用才省心

Java 7+ 提供的这两个工具方法，就是为避免手写时漏判null或写错组合逻辑。它们不是“语法糖”，而是防错刚需。

• Objects.equals(a, b)自动处理a或b为null的情况，比a.equals(b)安全得多
• Objects.hash(name, age, id)内部已做null判空，并按固定算法混合字段值，比手写31 * name.hashCode() + age更可靠
• 示例片段：

  public boolean equals(Object o) {
      if (this == o) return true;
      if (o == null || getClass() != o.getClass()) return false;
      Person person = (Person) o;
      return Objects.equals(name, person.name) &&
             Objects.equals(age, person.age);
  }
  <p>public int hashCode() {
  return Objects.hash(name, age);
  }</p>

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

IntelliJ 或 Eclipse 生成的equals()/hashCode()本身逻辑正确，但隐患藏在“选哪些字段”和“后续维护”里。

• 生成时漏选字段：比如新增了email字段并纳入equals()判断，但忘了勾选它进hashCode()生成逻辑 → 违反契约
• 继承场景下未处理父类字段：子类重写时若没调用super.equals()或super.hashCode()，父类状态就被忽略
• Lombok 的@EqualsAndHashCode默认只包含非静态、非瞬态字段，若你手动加了transient字段又想参与比较，就得显式用include参数声明

哈希表结构本身不复杂，但一旦字段可变、继承关系介入、或团队协作中有人只改equals()不碰hashCode()，问题就藏在运行时最意想不到的地方——比如某个缓存命中率突然掉到 0%。

本篇关于《equals与hashCode为何要同时重写？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！