摘要：在Java的世界里，每个对象都带着两张隐形身份证——equals是判定身份的核心标准，hashCode则是快速检索的通行证。这对看似独立的方法，实则遵循着编程世界的"量子纠缠"定律：只要动了equals，就必须对hashCode负责到底。
在Java的世界里，每个对象都带着两张隐形身份证——equals是判定身份的核心标准，hashCode则是快速检索的通行证。这对看似独立的方法，实则遵循着编程世界的"量子纠缠"定律：只要动了equals，就必须对hashCode负责到底。
想象这样一个场景：派出所给两人颁发相同身份证号（equals返回true），却在指纹库登记不同指纹（不同hashCode）。当需要紧急寻人时，系统通过指纹检索就会永远错过本应存在的对象。这正是Java集合框架底层运作的真实写照。
有个经典案例曾让无数程序员掉进坑里：某人精心重写了Employee类的equals方法，根据姓名、工龄、薪资判断对象相等性，却在存入HashSet时发现重复数据。经排查才发现hashCode仍在沿用Object类的内存地址计算方式，导致相同对象被分配到不同哈希桶。
哈希表就像快递分拣中心的智能机器人，它通过hashCode值确定包裹（对象）该进哪个分拣格（bucket）。当调用HashMap的put方法时：
计算键对象的hashCode值通过扰动函数生成最终哈希值根据哈希值确定存储位置这里隐藏着致命陷阱：若两个equals相等的对象hashCode不同，它们会被分配到不同分拣格。当通过新对象查找时，系统直接定位到空的格子，导致"对象明明存在却查不到"的灵异现象。
Java语言规范明确三大约束：
一致性法则：对象未修改时，多次调用hashCode必须返回相同值等价性法则：equals为true时，hashCode必须相同宽容性法则：equals为false允许hashCode相同（但应尽量避免）TreeSet可能重复存储相同对象，ConcurrentHashMap会出现线程安全问题，甚至JVM优化策略都会因此失效。
打开JDK的HashMap源码，查看putVal方法的关键代码片段：
Javaif (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k)))) // 覆盖原有值这里采用双重验证机制：
先用hashCode快速筛选再用equals精确匹配若只重写equals而忽视hashCode，就像给导弹装上红外制导却不配雷达——虽然能识别目标（equals正确），但永远找不到正确发射路径（hashCode错误）。
实测案例：用未重写hashCode的Person对象作为HashMap键
JavaMap map = new HashMap;Person p1 = new Person("张三", 25); // hashCode=123Person p2 = new Person("张三", 25); // hashCode=456map.put(p1, "程序员");map.get(p2); // 返回null！这种数据黑洞每年造成数百万小时的无效调试，成为Java开发者晋升路上的"百慕大三角"。
使用Java 7+的Objects工具类可完美解决：
Java@Overridepublic int hashCode { return Objects.hash(name, age, salary); }@Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass != o.getClass) return false; Person person = (Person) o; return age == person.age && Objects.equals(name, person.name) && Objects.equals(salary, person.salary);}这里暗藏三个精妙设计：
使用getClass而非instanceof，避免子类继承破坏对称性先比较地址快速返回，提升性能对浮点型使用Objects.equals避免精度误差好的hashCode实现要兼顾：
离散性：不同对象尽量不同hashCode稳定性：对象不变hashCode不变高效性：计算复杂度控制在O(1)对于包含集合字段的对象，推荐：
Javapublic int hashCode { int result = 17; result = 31 * result + name.hashCode; result = 31 * result + age; result = 31 * result + (projects != null ? projects.hashCode : 0); return result;}选择31这个质数的妙处：
31=2^5-1，可用移位优化：31*i = (i实验证明此数值离散性能最佳某电商系统在促销期间突然出现库存异常，经排查发现：
商品SKU对象重写了equals但未重写hashCode本地缓存使用ConcurrentHashMap存储查询时生成的新对象与原对象equals为true但hashCode不同导致缓存击穿，数据库瞬时流量暴增某金融系统出现资金重复结算：
交易流水对象hashCode依赖可变的交易时间字段线程池复用线程时未正确重置对象状态导致HashSet中出现两个equals相同的对象最终引发资金重复划转Java@Datapublic class User { private String uuid; private String username; private int authLevel;}@Data注解自动生成规范的equals和hashCode，但要注意：
避免使用可变字段集合字段需特殊处理equals and hashCode not pairedNon-final field used in equals/hashCodeequals does not check for null某团队启用检查后，代码缺陷率下降73%，线上事故减少61%。
完成代码编写后，请运行这个单元测试：
Java@Testpublic void testHashCodeContract { Object a = new MyClass(...); Object b = new MyClass(...); assertEquals(a.equals(b), (a.hashCode == b.hashCode)); if (a.equals(b)) { assertEquals(a.hashCode, b.hashCode); }}在Java中，equals与hashCode是受《对象关系法》保护的法定对象。它们的关系启示我们：在编程世界，表面的独立往往暗藏深层的契约。
来源：电脑技术汇
