在 Java 开发中，重写hashCode()方法是一个看似微小却影响深远的操作。许多开发者知道 “重写equals()时必须重写hashCode()”，却不理解背后的深层原因。事实上，hashCode()方法与equals()方法共同支撑着 Java 集合框架(尤其是HashMap、HashSet等哈希容器)的核心功能，其设计逻辑直接关系到数据存储的效率与准确性。小编将从哈希表原理出发，解析重写hashCode()的必要性、实现原则及常见误区，助你写出符合规范的 Java 代码。
一、先理解：hashCode () 的本质作用
hashCode()是 Java 中Object类的 native 方法(由底层 C/C++ 实现)，返回一个 int 类型的哈希值。其核心作用是为对象生成一个 “哈希码”，作为哈希容器中定位对象的 “索引”，类似图书馆中书籍的编号 —— 通过编号能快速找到书籍所在的书架，通过哈希码能快速定位对象在哈希表中的存储位置。
在哈希容器(如HashMap)中，数据存储流程为：
当添加对象key时，先调用key.hashCode()生成哈希码;
根据哈希码计算对象在哈希表中的 “桶位置”(如hashCode % 数组长度);
若该位置为空，直接存储对象;若已存在对象，通过equals()方法比较是否为同一个对象，避免重复存储。
可见，hashCode()的核心价值是 **“缩短查找路径，提升哈希容器的操作效率”**—— 若无哈希码，哈希容器需逐个比较所有对象(类似数组的线性查找)，时间复杂度为 O (n);有哈希码后，理想情况下可直接定位到目标位置，时间复杂度降至 O (1)。
二、为什么必须重写 hashCode ()?违反规则的后果
Java 语言规范明确规定：若两个对象通过equals()方法判断为相等，则它们的hashCode()必须返回相同的值;反之，若hashCode()返回不同值，则equals()必须判断为不相等。这一规则是哈希容器正确工作的基础，若仅重写equals()而不重写hashCode()，会导致哈希容器出现 “逻辑错误” 与 “效率问题”。
(一)反例：仅重写 equals ()，不重写 hashCode ()
假设定义一个User类，重写equals()判断 “id 相同则对象相等”，但未重写hashCode()：
java
运行
class User {
private int id;
private String name;
public User(int id, String name) {
this.id = id;
this.name = name;
}
// 仅重写equals()：id相同则认为相等
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
User user = (User) o;
return id == user.id;
}
// 未重写hashCode()，使用Object类的默认实现
}
此时，两个id相同的User对象会出现矛盾：
java
运行
public class HashCodeDemo {
public static void main(String[] args) {
User u1 = new User(1, "张三");
User u2 = new User(1, "李四");
// equals()判断为相等(id相同)
System.out.println(u1.equals(u2)); // 输出：true
// 默认hashCode()返回不同值(Object类基于对象内存地址生成哈希码)
System.out.println(u1.hashCode()); // 输出：356573597(示例值)
System.out.println(u2.hashCode()); // 输出：1735600054(示例值)
// 放入HashSet，本应视为同一个对象，却被重复存储
Set<User> set = new HashSet<>();
set.add(u1);
set.add(u2);
System.out.println(set.size()); // 输出：2(错误，应为1)
}
}
(二)问题分析：哈希容器的逻辑混乱
上述反例中，u1与u2通过equals()判断为相等，却因hashCode()返回不同值，导致：
重复存储：HashSet认为二者是不同对象(哈希码不同)，允许重复添加，违背Set“不存储重复元素” 的特性;
查找失败：若后续用u2查找HashSet中的u1，会先通过u2.hashCode()计算位置，该位置存储的是u2，而非u1，导致查找失败(set.contains(u2)返回true，但实际逻辑上应认为容器中已存在该对象)。
根本原因是破坏了 “相等对象必须有相等哈希码” 的规则，导致哈希容器无法正确识别 “逻辑相等” 的对象，失去其设计意义。
三、重写 hashCode () 的核心原则与实现方法
重写hashCode()需遵循两大原则，确保与equals()逻辑一致，同时兼顾哈希表效率：
(一)核心原则
一致性：若对象的equals()比较所用的信息未修改，则hashCode()多次调用应返回相同值(允许不同 Java 进程或程序执行时返回不同值，但同一进程内必须一致);
相等性：若a.equals(b) == true，则a.hashCode() == b.hashCode()必须成立;
分散性：若a.equals(b) == false，尽量让a.hashCode() != b.hashCode()(降低哈希冲突概率，提升容器效率)。
(二)实现方法：基于 equals () 的比较字段计算哈希码
hashCode()的计算应与equals()保持一致 ——equals()中用于比较的字段(如上例的id)，必须参与hashCode()的计算;equals()中未使用的字段(如上例的name)，不应参与计算，否则会违反 “相等性原则”。
1. 基础实现(手动计算)
以上述User类为例，正确重写hashCode()：
java
运行
@Override
public int hashCode() {
return id; // 直接返回id作为哈希码(因equals()仅比较id)
}
此时，u1与u2的hashCode()均为 1，HashSet会将它们视为同一对象，避免重复存储。
2. 多字段场景(推荐使用 Objects.hash ())
若equals()比较多个字段(如id和name)，需将所有字段纳入hashCode()计算，推荐使用Objects.hash()工具方法(自动处理 null 值)：
java
运行
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
User user = (User) o;
return id == user.id && Objects.equals(name, user.name);
}
@Override
public int hashCode() {
// 所有equals()中比较的字段均参与计算
return Objects.hash(id, name);
}
Objects.hash()会对每个字段调用hashCode()，再通过特定算法合并结果，确保多字段组合的哈希码唯一性。
3. 避免过度复杂的计算
哈希码的核心是 “快速定位”，而非 “绝对唯一”(允许哈希冲突，哈希容器会通过equals()解决)。因此，计算不应过于复杂(如避免循环遍历大型集合)，以免降低哈希容器的操作效率。
四、常见误区：重写 hashCode () 的典型错误
仅返回固定值(如 return 1)：
虽满足 “相等对象哈希码相等”，但所有对象会被分配到哈希表的同一个桶中，导致哈希容器退化为链表，时间复杂度变为 O (n)，彻底失去高效查找的优势。
使用未参与 equals () 的字段：
例如equals()比较id，hashCode()却使用name，会导致 “equals()相等的对象，hashCode()可能不同”，违反核心原则。
忽略 null 值处理：
若字段可能为 null，直接调用field.hashCode()会抛出NullPointerException，需手动判断(field == null ? 0 : field.hashCode())，或使用Objects.hash()(自动处理 null，返回 0)。
重写hashCode()的本质是维护与equals()的逻辑一致性，确保哈希容器能正确识别 “逻辑相等” 的对象，同时通过合理的哈希码计算提升容器效率。记住：重写equals()必须重写hashCode()，二者如同 “孪生兄弟”，共同保证 Java 哈希机制的正确性。
