17370845950

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()：

• 两个 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() 就必须同时基于这两个字段生成。