Java集合判等为何要重写equals和hashCode

Java集合（尤其是HashMap、HashSet等基于哈希的集合）判断对象是否相等，依赖于equals()和hashCode()两个方法的协同工作：先用hashCode()快速定位存储桶，再用equals()精确比对；若只重写equals()而忽略hashCode()，逻辑上相等的对象可能因哈希值不同被散列到不同桶中，导致重复添加、查找失败、删除无效等严重功能问题——这并非性能缺陷，而是直接违反Java规范中“相等对象必须具有相同哈希码”的核心契约；因此，只要重写equals()，就必须同步基于相同字段重写hashCode()，推荐使用Objects.hash()确保安全、简洁与一致性。

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

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~