在Java开发里，实体类经常需要放到集合中使用，或者作为Map的键。这时候equals和hashCode两个方法就不是可有可无的装饰，而是决定程序行为正确与否的关键。如果实现不当，会出现对象明明逻辑相等却查不到、集合去重失效等难以排查的问题。
为什么必须同时重写equals和hashCode
Java规范明确规定：如果两个对象根据equals方法是相等的，那么调用这两个对象的hashCode方法必须产生相同的整数结果。反过来不要求hashCode相同的对象equals一定相等，但hashCode不同的对象equals必须不相等。这条约定是HashMap、HashSet等基于哈希的集合能够正常工作的基础。
当我们把对象放入HashSet时，集合先调用hashCode确定存储桶，再用equals在桶内比较。如果只重写了equals而没有重写hashCode，两个逻辑相等的对象可能得到不同的哈希值，被放到不同的桶里，集合就会认为它们不相等，导致重复元素出现或者无法检索。
基于业务主键的实现方式
实体类的相等性通常取决于业务主键或数据库主键，而不是对象的内存地址。比如一个用户实体，只要id相同就应当视为同一个用户。下面给出一个使用id和username作为相等依据的实现示例。
import java.util.Objects;
public class User {
private Long id;
private String username;
private String email;
public User(Long id, String username, String email) {
this.id = id;
this.username = username;
this.email = email;
}
@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(username, user.username);
}
@Override
public int hashCode() {
return Objects.hash(id, username);
}
// 省略getter和setter
}
上面的代码使用了Objects.equals来避免空指针，使用Objects.hash来生成哈希值。这种写法简洁且安全。需要注意，参与equals比较的字段必须和参与hashCode计算的字段保持一致，否则会破坏前文提到的约定。
如果实体类有继承结构，要考虑父类字段是否参与比较。使用getClass() != o.getClass()的方式会要求类型严格一致，这能防止子类伪装成父类破坏对称性；若希望子类对象能和父类对象在id相等时视为相等，可以改用instanceof判断并只比较共同字段，但这需要谨慎设计。
使用IDE自动生成的注意事项
多数开发者习惯用IntelliJ IDEA或Eclipse自动生成equals和hashCode。这能减少手写错误，但带来一个隐患：当实体类新增字段时，容易忘记重新生成方法，导致新字段不参与相等判断。
// 假设后来增加了phone字段，但忘记重新生成方法 private String phone; // 此时equals仍只比较id和username // 两个id和username相同但phone不同的User会被认为是相等的
为避免这类问题，可以在代码评审清单中加入检查项，或者使用Lombok的@EqualsAndHashCode注解，并明确指定of属性来锁定参与计算的字段。这样即使类结构变化，也能通过编译期提示察觉。
常见误区与最佳实践
一个典型误区是把可变字段放进hashCode计算。如果对象放入HashSet后，其参与hashCode的字段被修改，它的哈希桶位置就变了，集合内部无法再找到它，造成内存泄漏式的问题。因此，作为集合元素的实体，相等依据字段应当是不可变的。
| 场景 | 推荐策略 |
|---|---|
| 数据库实体 | 使用主键id，且id在持久化后不变 |
| 值对象 | 所有字段参与，且全部不可变 |
| DTO传输对象 | 按业务语义选择自然键，避免比较所有字段 |
总结来说，正确实现实体类的equals和hashCode，核心在于选对不变的自然键、保持两个方法字段一致、规避可变字段参与计算。只要遵循这些原则，就能在集合操作与逻辑判断中避免绝大多数隐性错误。
equalshashCodeJava_entity修改时间：2026-08-01 11:09:10