合理实现hashCode能显著降低哈希冲突概率，需满足一致性、均匀性、高效性，且必须与equals逻辑严格一致；违反Java规范会导致HashMap行为异常。
重写 hashCode 本身不能“避免碰撞灾难”，但合理实现能显著降低哈希冲突概率，配合 equals 正确实现，才能让 HashMap 高效工作。关键不在“避免碰撞”（哈希碰撞在数学上无法完全消除），而在于让散列值分布均匀、计算高效、与 equals 逻辑严格一致。
核心原则：一致性 + 均匀性 + 高效性
Java 规范强制要求：
– 如果两个对象 equals() 返回 true，它们的 hashCode() 必须相同；
– 反之不成立（不同对象可以有相同 hash）；
– 同一对象多次调用 hashCode() 必须返回相同值（只要影响 equals 的字段没变）。
违反这些原则会导致 HashMap 行为异常（如 get() 找不到已存入的键）。
怎么写一个靠谱的 hashCode（以常见 POJO 为例）
假设有一个用户类：
class User {
private String name;
private int age;
private String email;
}推荐写法（JDK 7+ 推荐使用 Objects.hash()）：
立即学习“Java免费学习笔记（深入）”；
@Override
public int hashCode() {
return Objects.hash(name, age, email);
}等价于手动写（理解原理用）：
@Override
public int hashCode() {
int result = 1;
result = 31 * result + (name == null ? 0 : name.hashCode());
result = 31 * result + age;
result = 31 * result + (email == null ? 0 : email.hashCode());
return result;
}说明：
- 用质数（如 31）做乘数：减少低位信息丢失，增强字段组合的区分度；
-
null 安全处理：避免
NullPointerException，统一用 0 替代； -
只包含参与 equals 比较的字段：如果
equals比较了name和age，但没比email，那hashCode里也不能含email，否则违反一致性； -
顺序敏感：
Objects.hash(a, b)和Objects.hash(b, a)结果不同，要和equals中的字段顺序逻辑对齐（通常按字段声明顺序即可）。
哪些写法会引发“碰撞灾难”？
以下写法看似简单，实则危险：
-
固定返回一个常量（如
return 42;）：所有对象 hash 相同 → 全部挤进同一个桶 →HashMap退化为链表（Java 8+ 超过阈值转红黑树，但仍远慢于正常 O(1)）； -
只用一个字段（如
return name.hashCode();）：当大量用户姓名相同时（如“张三”），冲突激增； -
用了未参与 equals 的字段：比如
equals只比id，但hashCode还算了name→ 同一 id 不同 name 的对象可能 hash 不同 →HashMap查不到； -
在 hashCode 中修改对象状态：比如调用
name.toUpperCase()或触发懒加载 → 违反“同一对象多次调用结果相同”的契约。
辅助建议：验证与工具
– 用 IDE（IntelliJ / Eclipse）自动生成 hashCode 和 equals，它默认遵循规范；
– 单元测试中验证：对两个 equals 为 true 的对象，断言其 hashCode() 相等；
– 对高并发或大数据量场景，可考虑用 java.util.Objects.hash（线程安全、空安全、简洁）；
– 极端性能敏感时，可手写精简版（如用位运算替代乘法），但务必先压测，多数情况没必要。
