Java集合判断对象相等需同时重写equals()和hashCode()，因先用hashCode()定位桶再用equals()确认；若只重写equals()，逻辑相等的对象可能被散列到不同桶，导致重复添加、查找失败等问题。
Java集合（尤其是基于哈希的集合，如 HashMap、HashSet、LinkedHashMap）判断两个对象是否“相等”时，并不是只靠 equals() 一个方法，而是先用 hashCode() 快速筛选，再用 equals() 精确确认。如果只重写 equals() 却不重写 hashCode()，集合就可能“认不出”逻辑上相等的对象，导致重复存入、查不到、删除失败等严重问题。
哈希集合怎么判断“同一个元素”？
以 HashSet 为例，它底层是哈希表结构：
- 添加元素时，先调用对象的
hashCode()，算出一个整数，再对数组长度取模，得到该元素应存放的“桶”（bucket）位置； - 如果这个桶里已有元素，就遍历桶内所有对象，逐个调用
equals()比较——只有equals()返回true才认为已存在，不再添加； - 查找或删除时，同样先根据
hashCode()定位到桶，再在桶内用equals()匹配。
也就是说：hashCode 不同 → 绝对不在同一个桶 → 根本不会调用 equals 去比。这是性能优化的关键，但也成了隐患源头。
不重写 hashCode 会出什么问题？
假设你定义了一个 User 类，只重写了 equals()（比如按 id 判断相等），但没重写 hashCode()：
立即学习“Java免费学习笔记（深入）”；
- 两个
id=100的User对象，equals()返回true（逻辑相等）； - 但它们继承自
Object的hashCode()默认基于内存地址生成，大概率返回不同值； - 结果：这两个对象被放进
HashSet的两个不同桶里，集合认为它们是“两个不同元素”； - 后续用其中一个去
contains()或remove()，很可能找不到——因为去错了桶。
为什么必须保证“相等则哈希码相同”？
这是 Java 规范明确要求的契约（Contract）：
-
一致性前提：若
a.equals(b) == true，则a.hashCode() == b.hashCode()必须为true； - 反过来说，
hashCode()相同，equals()不一定为true（允许哈希冲突，这是正常现象）； - 但一旦违反“相等必同哈希”，哈希集合的行为就不可预测——不是效率低，而是功能错误。
怎么安全地一起重写？
核心原则：参与 equals() 比较的字段，也必须参与 hashCode() 计算。
- 用
Objects.hash(...)最省心（JDK7+）：传入所有关键字段，自动处理 null 和质数运算； - 手动计算常用 31 作为乘数（如
result = 31 * result + field.hashCode()），兼顾分布与性能； - 确保
equals()中的判空、类型检查、字段比较，和hashCode()中用到的字段完全对应。
例如 Person(name, age) 类，equals() 比较 name 和 age，那 hashCode() 就必须同时基于这两个字段生成。
