重写hashCode的核心原因是保证对象在哈希集合中能被正确存储和查找；必须与equals协同，若只重写equals不重写hashCode，会导致相等对象散列到不同桶，引发查找不到、重复添加等问题。
Java中重写hashCode方法，核心原因就一个：**保证对象在哈希集合（如HashMap、HashSet）中能被正确存储和查找**。这背后不是随便写的，而是严格遵循面向对象中“相等对象必须有相同哈希码”的契约——也就是equals与hashCode的协同规则。
为什么只重写equals不行？
如果只重写equals却不重写hashCode，会导致逻辑矛盾：
- 两个逻辑上相等的对象（
a.equals(b) == true），可能因继承自Object的默认hashCode（基于内存地址）而返回不同值； - 一旦放进
HashSet或作为HashMap的key，它们会被散列到不同桶里，结果就是“明明相等，却查不到”“重复添加成功”等诡异行为。
hashCode与equals的强制约定
Java规范明确要求两者必须保持一致：
-
如果
a.equals(b)返回true，那么a.hashCode()必须等于b.hashCode()； - 反之不成立：哈希码相同，对象不一定相等（哈希冲突允许，但要靠
equals兜底）； - 同一对象在同一次运行中多次调用
hashCode，必须返回相同整数（只要用于equals比较的字段没变）。
怎么安全地重写hashCode？
推荐用Objects.hash(...)——简洁、高效、避免空指针：
立即学习“Java免费学习笔记（深入）”；
public class Person {
private String name;
private int age;
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
return age == person.age && Objects.equals(name, person.name);
}
@Override
public int hashCode() {
return Objects.hash(name, age); // 自动处理null，按字段顺序计算
}
}
关键点：
- 参与
hashCode计算的字段，必须和equals中用于判断相等的字段完全一致； - 避免使用可变字段（比如后面会修改的
name），否则对象放入哈希集合后修改字段，会导致再也找不回来； - 不需要追求“绝对不冲突”，只要分布相对均匀、计算快，就够了。
不重写的实际后果示例
假设你有一个Student类，只重写了equals（按学号判断相等），但没重写hashCode：
Student s1 = new Student("001");
Student s2 = new Student("001");
System.out.println(s1.equals(s2)); // true
System.out.println(s1.hashCode() == s2.hashCode()); // false（默认是内存地址）
Set<Student> set = new HashSet<>();
set.add(s1);
System.out.println(set.contains(s2)); // false！本该是true
这就是违反契约带来的真实问题——集合失效，业务逻辑出错。
基本上就这些。重写hashCode不是为了炫技，而是守住OOP对象一致性底线。只要记住：改了equals，hashCode必须同步改，且用同样字段，用Objects.hash最省心。
