为什么 equals 和 hashCode 要保持一致？｜字节跳动后端开发面经解析

60 秒回答模板

可以从对象契约和容器实现两个角度回答。Java 规定：如果两个对象 equals 返回 true，那么它们的 hashCode 必须相同；如果 hashCode 相同，equals 不一定为 true。HashMap、HashSet 的查找流程通常是先根据 hashCode 定位桶，再在桶内用 equals 做精确匹配。如果 equals 和 hashCode 不一致，相等对象可能被定位到不同桶，容器就没有机会比较 equals，表现为 put 出现重复 key、get 取不到值、remove 删除失败。总结就是：hashCode 决定查找范围，equals 决定最终相等，二者必须描述同一套对象身份语义。

考点 定位阶段

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

一致性来自 Object 契约

Java 对 Object 的 equals 和 hashCode 有明确约定：在对象参与比较的信息没有改变的前提下，多次调用 hashCode 应保持一致；如果两个对象 equals 为 true，那么它们的 hashCode 必须相等；但两个对象 hashCode 相等时，equals 不一定为 true。这个契约让所有基于哈希的集合能够用统一方式处理自定义对象，而不需要理解每个类内部的业务语义。

HashMap 的查找分两步

HashMap 并不是拿到一个 key 后直接遍历所有元素并调用 equals。它会先根据 key 的 hashCode 计算桶位置，把搜索范围缩小到一个桶或一个桶内的链表、树结构，然后再对候选节点做 equals 比较。如果两个业务上相等的对象 hashCode 不同，它们可能进入不同桶，后续 equals 根本没有被调用的机会，容器自然无法判断它们其实是同一个 key。

不一致会破坏集合语义

当 equals 认为两个对象相等，而 hashCode 不同，HashSet 可能同时保存两个“相等”的元素，违背集合不重复的语义。HashMap 中则可能出现两个逻辑相同的 key，对其中一个 key put 的值，用另一个 equals 相等的 key 却 get 不出来。更糟的是 remove 和 containsKey 也会出现不稳定表现，这类问题通常不是编译期错误，而是运行期数据行为异常。

一致不代表完全相同逻辑

equals 和 hashCode 保持一致，并不是说二者实现代码要完全一样，而是它们必须基于同一套相等性定义。equals 做精确判断，hashCode 做快速分桶，它们职责不同。hashCode 可以存在冲突，也就是说不相等对象可以有相同哈希值；这种情况下容器还会继续调用 equals 区分。真正不允许的是 equals 为 true 的对象落到不同哈希值上。

设计类时要同时维护

实际编码中，只要重写 equals，通常就必须同步重写 hashCode。尤其是实体对象、值对象、复合 key、集合元素等场景，更要明确哪些字段定义对象身份，并让两个方法围绕同一批字段实现。IDE 生成方法、record、不可变值对象都能降低出错概率，但开发者仍需要判断字段语义是否正确，而不是机械地把所有字段都纳入比较。

易错点

认为只要 equals 写对了，HashMap 就一定能正常识别相同 key。
误以为 hashCode 相同就代表两个对象一定相等。
重写 equals 后忘记重写 hashCode，导致哈希集合出现异常行为。
把一致性理解成两个方法代码完全相同，而不是语义字段保持一致。

面试官追问

只重写 equals 不重写 hashCode 会怎样？

对象在普通 equals 比较中可能表现正常，但放入 HashMap、HashSet 后会出问题。因为默认 hashCode 通常基于对象身份，不同实例即使 equals 相等，也可能有不同哈希值。

hashCode 相同的两个对象一定 equals 吗？

不一定。哈希冲突是允许的，两个不相等对象可以拥有相同 hashCode。容器遇到这种情况会继续使用 equals 判断，最多影响性能，不会直接破坏正确性。

为什么 HashMap 不直接只用 equals？

如果只用 equals，查找时可能需要遍历大量元素，复杂度接近线性。hashCode 可以先把数据分散到不同桶中，把比较范围缩小，从而让平均查找效率接近常数级。

equals 和 hashCode 应该使用所有字段吗？

不一定。应该使用能定义对象逻辑身份的字段。把缓存、展示文本、统计值、更新时间等无关字段纳入其中，可能导致相等性语义不稳定或不符合业务预期。