必须同步重写hashcode，因为java规范要求逻辑相等对象必须具有相同哈希码，否则hashmap、hashset等容器会因散列到不同桶而无法定位或查找不到对象。
重写 equals 时必须同步重写 hashCode，核心就一条：**保证逻辑相等的对象能被哈希集合正确识别和定位**。这不是可选项，而是 Java 规范强制要求的契约——违反它，HashMap、HashSet 等容器就会“失灵”。
哈希表查找依赖两步配合
Java 的哈希集合（如 HashSet、HashMap 的 key）底层是数组加链表/红黑树。插入或查询时严格按顺序执行：
- 先调用对象的
hashCode()，算出它该落在哪个数组索引（桶）里 - 若该桶已有元素，再用
equals()逐个比对，确认是否真正重复
如果只改了 equals 让两个对象“内容相同即相等”，但没改 hashCode，它们默认仍按内存地址生成不同哈希值——结果就是被分到不同桶里。后续调用 set.contains(b) 或 map.get(b) 时，程序根本不会去查另一个桶，直接返回 false 或 null，哪怕对象业务上完全一样。
不重写的实际故障表现
典型例子：自定义 Person 类，仅重写 equals 比较 name 和 age，但保留 Object.hashCode()：
-
p1.equals(p2)返回true（姓名年龄都相同） -
p1.hashCode() == p2.hashCode()却是false（因内存地址不同） -
set.add(p1); set.contains(p2)结果为false——本该命中却查不到 -
map.put(p1, "A"); map.get(p2)返回null——键明明“相等”，却取不出值
重写时的关键守则
二者不是随便写写，必须遵守一致性原则：
- 参与
equals判断的字段，也必须全部参与hashCode计算（比如都用name和age） - 推荐用
Objects.hash(name, age)，自动处理null，避免空指针 - 不要在
hashCode中使用后续可能修改的字段（如普通 setter 可改的属性），否则对象进集合后再改字段，哈希值就变了，再也找不回来 - IDE（如 IntelliJ）的 “Generate → equals and hashCode” 功能可一键生成，安全省心
这是规范契约，不是性能优化技巧
有人误以为重写 hashCode 是为了“提升效率”。其实首要目的是**行为正确性**。Object 类文档白纸黑字写着：“若 a.equals(b) 为 true，则 a.hashCode() 必须等于 b.hashCode()”。这是一条铁律。哪怕你当前代码没用到任何哈希集合，只要未来有人把它放进 HashMap，或传给 Collections.frequency() 这类工具方法，问题就会暴露。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
