hashcode 方法直接影响散列表性能，决定查找效率而非能否存储；设计不当会导致 o(1) 操作退化为 o(n)；必须与 equals 保持一致，确保稳定性、覆盖所有相关字段，并优先使用 objects.hash 等安全方法。
hashCode 方法直接影响 HashMap、HashSet 等散列表集合的查找、插入和删除效率——它不决定“能不能存”，而决定“找得快不快”。设计不当会把本该 O(1) 的操作拖慢到 O(n)，尤其在数据量大时表现明显。
定位桶是第一步，哈希值决定初始位置
哈希集合底层是数组 + 链表/红黑树。调用 put() 或 add() 时，JVM 先执行 key.hashCode()，再经扰动（如 h ^ (h >>> 16)）和位运算（index = hash & (table.length - 1)）算出桶下标。这步越快、越分散，后续越省事。
- 如果所有对象返回相同哈希值（比如恒为 0），全部挤进同一个桶 → 变成链表遍历，contains() 平均比较次数从 1–2 次飙升至 N/2
- 哪怕只是部分字段参与计算（如只用 id），而测试数据中 id 大量重复，也会局部退化，性能抖动不易察觉
稳定性比“均匀”更重要
很多开发者追求“哈希分布均匀”，但更关键的是：只要 equals 所依赖的字段没变，hashCode 就不能变。否则对象存进 HashMap 后可能再也找不到。
- 用 ArrayList.size() 当哈希依据 → 后续 add 元素后 size 改变 → hashCode 改变 → 对象在 map 中“消失”
- 字段含浮点数 → 0.0 和 -0.0 equals 返回 true，但默认 hashCode 不同 → 必须统一用 Double.doubleToLongBits(x) 转换
- 字符串忽略大小写比较 → equals 用 toLowerCase()，hashCode 也得用 toLowerCase().hashCode() 对齐
record 类省心但有隐性约束
Java 14+ 的 record 自动生成 hashCode()，逻辑等价于 Objects.hash(field1, field2, …)，按声明顺序组合字段哈希值。它规避了手写遗漏，但要注意：
- 字段顺序影响结果：record A(String a, int b) 和 record B(int b, String a) 即使字段相同，hashCode 也不同 → 不能混用作 Map key
- null 字段被安全处理，但若字段是可变集合（如 List），而该 List 后续被修改，哈希值就变了 → record 要求不可变，别塞可变对象进去
- 验证很简单：new Person("a", 1).hashCode() 和 new Person("a", 2).hashCode() 应该不同；相同实例多次调用应返回同一值
手写或生成时三个动作不能少
自定义类重写 hashCode，不是写个公式就行，必须闭环验证：
- 覆盖所有参与 equals 判断的字段 —— 少一个，就违反 equals/hashCode 契约
- 优先用 Objects.hash(a, b, c)，它自动判空、内部优化，比手动写 31 * result + a.hashCode() 更可靠
- 字段是数组、集合或自定义对象时，要用对应方法：Arrays.hashCode(arr)、Objects.hash(collection)、确保嵌套对象自身 hashCode 正确
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
