Java中hashCode方法必须实现确定性计算：只要对象状态不变，无论何时何地调用都返回相同整数；重写equals时必须同步重写hashCode，且二者所依据的字段和算法必须严格一致，否则违反契约导致HashMap等集合异常。
Java 中的 hashCode 方法要实现确定性计算结果，核心在于：**只要对象状态不变，无论何时、在哪次运行中调用，都必须返回相同的整数**。这不是“随机稳定”，而是由对象内容严格决定的、可复现的计算过程。
关键前提：重写 equals 时必须重写 hashCode
如果自定义类重写了 equals 方法（比如按 name + age 判断相等），那么默认的 Object.hashCode()（基于内存地址或 JVM 内部机制）就不再满足契约——相等的对象可能得到不同哈希值。此时必须手动重写 hashCode，且计算逻辑必须与 equals 中用于比较的字段完全一致。
确定性实现的三要素
-
输入固定：只使用
equals中参与比较的不可变字段（如 final 字段），避免引用易变状态（如当前时间、随机数、外部缓存值） - 算法固定：采用确定性数学运算（加法、乘法、位运算），不依赖线程、系统时间、JVM 启动参数等外部变量
- 顺序与组合一致：字段参与计算的顺序、组合方式（如 31 * h + f）每次相同，不因运行环境变化而改变
推荐实现方式（兼顾正确性与效率）
以下两种方式都能保证确定性，但适用场景略有不同：
-
用
Objects.hash(...)：简洁安全，适合多数场景。它对传入字段逐个调用其hashCode()，再按固定算法组合（内部使用 31 为乘子）。例如：@Override public int hashCode() { return Objects.hash(name, age, id); } -
手写组合算法：避免
Objects.hash的数组创建开销（尤其高频调用时）。典型写法：int h = 17;<br>h = 31 * h + Objects.hashCode(name);<br>h = 31 * h + age;<br>h = 31 * h + Objects.hashCode(id);<br>return h;
哪些做法会破坏确定性？
- 在
hashCode()中读取非 final 字段，且该字段后续可能被修改（如user.setAge(25)后再次调用hashCode()） - 调用
System.nanoTime()、Math.random()或任何依赖运行时环境的方法 - 使用未重写
hashCode()的第三方对象（如自定义集合类未规范实现），导致其哈希值本身就不稳定 - 字段顺序在不同版本代码中不一致（比如先 age 后 name，后来改成先 name 后 age），虽不违法，但会改变哈希分布，影响序列化兼容性
确定性不是“让哈希值看起来一样”，而是让哈希值成为对象状态的函数映射——状态不变，结果必同。做到这点，HashMap、HashSet 才能正常工作，序列化/反序列化、分布式缓存等场景才不会出错。
立即学习“Java免费学习笔记（深入）”；
