equals与hashCode如何配合使用

今天golang学习网给大家带来了《equals与hashCode关系解析》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

重写 equals() 时必须同步重写 hashCode()，且两者依据的字段严格一致；否则 HashMap、HashSet 等集合行为异常。推荐用 Objects.hash() 生成 hashCode，避免手工计算。

equals 返回 true 时，hashCode 必须相等

这是 Java 规范强制要求的“黄金法则”：如果 equals() 判断两个对象逻辑相等，那它们的 hashCode() 值必须完全一致。否则，像 HashMap、HashSet 这类哈希集合会直接失效——对象明明该被查到，却永远找不到。

• 典型现象：往 HashSet 里加了对象 A，再用内容相同的对象 B 调用 contains(B)，结果返回 false
• 根本原因：B 的 hashCode() 和 A 不同，导致哈希表去错了“桶”，压根没走到 equals() 比较那一步
• 注意：这个约束是单向的——hashCode() 相等，equals() 不一定为 true（允许哈希冲突）

不重写 hashCode 就只重写 equals 是危险操作

很多开发者改了 equals()，却忘了同步更新 hashCode()，结果埋下隐蔽 bug。因为 Object 默认的 hashCode() 基于内存地址，而你重写的 equals() 已经按业务字段（比如 id、name）判断相等，两者彻底脱节。

• 错误示例：User 类重写了 equals() 比较 id，但没重写 hashCode() → 两个 id 相同的 User 实例，hashCode() 却不同
• 后果：作为 HashMap 的 key 时，第二次 put() 会新增 entry 而非覆盖；get() 也取不到值
• 安全做法：只要重写 equals()，就立刻重写 hashCode()，且两者依据的字段必须严格一致

怎么写一个靠谱的 hashCode 方法

手写 hashCode() 不必追求完美散列，关键是稳定、一致、基于 equals() 所用字段。JDK 自带的 Objects.hash(...) 是最稳妥的选择。

• 推荐写法：return Objects.hash(id, name, age); —— 字段顺序和 equals() 中的判等顺序保持一致
• 避免魔数运算：别写类似 id * 31 + name.hashCode() * 7 这种易错、难维护的手工计算
• 一致性前提：只要参与 equals() 判等的字段没变，hashCode() 就不能变；可变字段（如临时状态）绝不能参与计算
• 性能提示：字段越多、越分散，哈希冲突概率越低，但实际影响有限；比起“最优”，“正确”和“可读”更重要

什么时候可以不碰 equals 和 hashCode

不是所有类都需要重写。只有当你明确需要“内容相等”语义，并且对象会进入哈希集合或作为 Map 键使用时，才必须动手。

• 安全场景：纯数据传输对象（DTO）、工具类、只做局部计算不存入集合的临时对象 → 用默认实现完全没问题
• 高危场景：实体类（User/Order）、VO、作为 HashMap 的 key、放进 HashSet 去重、缓存 key → 必须检查是否已重写二者
• IDE 提示很关键：IntelliJ / Eclipse 都能一键生成符合规范的 equals() 和 hashCode()，比手写更可靠

真正容易被忽略的是：即使你用了 Lombok 的 @EqualsAndHashCode，也要确认它选中的字段和业务判等逻辑一致——比如是否误包含了数据库自增主键、时间戳这类可能变化的字段。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《equals与hashCode如何配合使用》文章吧，也可关注golang学习网公众号了解相关技术文章。