重写 equals 后必须重写 hashcode，否则在 hashmap、hashset 中会出现查找失败、重复添加等问题；根本原因是 java 规范要求 equals 为 true 时 hashcode 必须相等，且应使用 objects.hash() 包含所有 equals 中参与比较的字段并保持顺序一致。
重写 equals 后必须重写 hashCode
不重写 hashCode 会导致对象在 HashMap、HashSet 等基于哈希的集合中行为异常——比如明明 equals 返回 true，却查不到、删不掉、重复添加。这不是“可能出问题”，而是只要用了哈希集合就一定会触发。
根本原因：Java 规范强制要求，如果两个对象 equals 返回 true，它们的 hashCode 必须相等；反之不成立。违反这条，HashMap 的内部桶定位逻辑就直接失效。
- 只重写
equals不重写hashCode→ 对象在HashSet中可能被当成不同元素重复插入 - 重写了
hashCode但没覆盖所有equals用到的字段 → 两个逻辑上相等的对象算出不同哈希值 → 查不到 - 用随机数、时间戳、对象地址（如
System.identityHashCode(this)）生成hashCode→ 每次调用结果不同 → 哈希集合彻底不可用
hashCode 应该包含哪些字段
只包含 equals 方法里实际参与比较的字段。多一个、少一个、类型不一致，都会破坏一致性。
常见错误是忽略 null 安全或字段类型差异。例如 String 字段要用 Objects.hashCode(name) 而不是 name.hashCode()，否则 name == null 时直接抛 NullPointerException。
立即学习“Java免费学习笔记（深入）”；
- 基本类型（
int、boolean等）直接参与计算，boolean建议转成1/0 - 引用类型统一用
Objects.hashCode(field)，它能安全处理null - 数组字段不能直接用
array.hashCode()（那是引用哈希），得用Arrays.hashCode(array) - 浮点数慎用：
float用Float.floatToIntBits(f)，double用Double.doubleToLongBits(d)，避免-0.0和0.0哈希不同
推荐写法：用 Objects.hash(...) 一行搞定
这是最不容易出错的方式，底层已处理 null、数组、浮点数转换等细节，语义清晰，可读性强。
示例：
public class User {
private String name;
private int age;
private List<String> roles;
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
User user = (User) o;
return age == user.age &&
Objects.equals(name, user.name) &&
Objects.equals(roles, user.roles);
}
@Override
public int hashCode() {
return Objects.hash(name, age, roles); // ← 就这一行，字段顺序和 equals 保持一致
}
}
注意：Objects.hash 参数顺序必须和 equals 中字段比较顺序一致，否则极端情况下可能因哈希碰撞分布差异引发性能退化（虽不破坏正确性，但属于隐性坑）。
IDE 自动生成的 hashCode 为什么有时也不可靠
IntelliJ 或 Eclipse 生成的代码一般没问题，但有两个典型例外：
- 手动改过
equals逻辑（比如加了新字段或调整了条件），但忘了同步更新hashCode→ 一致性立刻被破坏 - 字段类型是自定义类，而该类本身没正确实现
hashCode→ 整个链路失效，比如private Address address;，但Address类没重写hashCode
真正保险的做法是：每次修改参与 equals 判断的字段后，立刻检查 hashCode 是否包含它，并确认其类型是否具备稳定的哈希行为。这点容易被跳过，尤其在迭代开发中。
