hashCode 实现不当会导致 HashMap、HashSet 性能从 O(1) 退化至 O(n)——所有元素挤入同一桶形成链表；典型错误是恒返回 0 或仅依赖重复字段，而 record 虽自动生成但需注意字段顺序与不可变性。
hashCode 直接决定 HashMap、HashSet 等散列表集合的查找和插入效率——如果实现不当，HashMap 会从平均 O(1) 退化成接近 O(n) 的链表遍历。
为什么 hashCode 写错会让 HashSet 变慢十倍？
Java 集合（如 HashSet）底层用数组 + 链表/红黑树存储元素，先靠 hashCode() 定位到“桶”（数组下标），再在桶内用 equals() 比较。一旦所有对象返回相同哈希值（比如恒为 0 或 1），所有元素都会挤进同一个桶，整个集合就变成单链表。
- 现象：插入 10 万条记录耗时从 20ms 涨到 2s+，
contains()平均比较次数从 1–2 次变成 5 万次 - 典型错误：
@Override public int hashCode() { return 0; // ❌ 绝对禁止！ } - 更隐蔽的坑：只用一个字段（如只用
id）计算哈希，而业务中id大量重复（如测试数据全为1）
record 类的 hashCode 是“开箱即用”，但要注意字段顺序和 null
Java 14+ 的 record 自动生成 hashCode()，逻辑等价于 Objects.hash(field1, field2, ...)，按声明顺序组合字段哈希值。它省去了手写错误，但仍有两个关键约束：
- 字段顺序影响结果：
record A(String a, int b) { }和record B(int b, String a) { }即使字段类型相同，hashCode()也不同 → 不能混用作 Map key -
null字段被安全处理（Objects.hash()内部判空），但若字段本身是可变容器（如List），而该 List 后续被修改，会导致哈希值变化 →record要求不可变，所以别把可变对象塞进去 - 验证方式：打印
new Person("a", 1).hashCode()和new Person("a", 2).hashCode()，确认数值确实不同
自定义类重写 hashCode 时，这三件事必须做对
手写 hashCode() 不难，但漏掉任一环节都可能引发线上性能抖动：
立即学习“Java免费学习笔记（深入）”；
- ✅ 必须覆盖所有参与
equals()判断的字段 —— 少一个，就违反equals/hashCode契约 - ✅ 推荐用
Objects.hash(a, b, c)，而不是手动写31 * result + a.hashCode()；前者自动处理null，且 JDK 已优化过 - ✅ 如果字段是数组（如
byte[]）、集合或自定义对象，必须用对应工具方法：
— 数组用Arrays.hashCode(arr)
— 集合/Map 用Objects.hash(collection)（它内部调用collection.hashCode()）
— 自定义对象确保其自身hashCode()正确，否则污染上游
最常被忽略的一点：hashCode 的稳定性比“分布均匀”更重要。哪怕你用 MD5 做哈希，只要对象状态不变，结果就得恒定；反之，若在 hashCode() 里调用了 new Date().getTime() 或 System.nanoTime()，放进 HashMap 后再也找不回来。
