结论：hashCode本身不提升效率，它与equals配合使哈希表能快速定位“可能存放该对象的桶”，将平均查找时间从O(n)降至接近O(1)；关键在于散列值稳定、均匀且与equals逻辑严格一致。
直接说结论：hashCode 本身不提升效率，它和 equals 配合，让哈希表能快速定位到“可能存放该对象的桶”，从而把平均查找时间从 O(n) 降到接近 O(1)。关键不是 hash 算法多复杂，而是散列值是否稳定、均匀，且与 equals 逻辑严格一致。
哈希表是怎么靠 hashCode 快速定位的
HashMap、HashSet 这类集合底层是数组 + 链表/红黑树。每次存取时：
- 先调用对象的 hashCode()，得到一个 int 值；
- 用这个值对数组长度取模（比如 index = hashCode & (table.length - 1)），算出它大概率在哪个数组下标位置（即“桶”）；
- 只在这个桶里遍历比较（用 equals），不用扫整个集合。
如果所有对象 hashCode 都返回 0，它们全挤进第一个桶，哈希表就退化成链表，查找又变回 O(n)。
重写 hashCode 必须遵守的两个硬性要求
否则 HashMap 可能“存进去却找不到”，HashSet 会误判重复：
立即学习“Java免费学习笔记（深入）”；
- 一致性：同一个对象，只要参与 equals 比较的字段没变，多次调用 hashCode() 必须返回相同值；
- 协同性：如果 a.equals(b) 返回 true，那么 a.hashCode() 和 b.hashCode() 必须相等。
反过来不强制——hashCode 相同，equals 不一定为 true（这就是哈希冲突，正常现象），但尽量让不同对象的散列值分布均匀，能减少冲突、提升性能。
怎么写出安全又靠谱的 hashCode
别手写质数乘法或位运算，容易出错。推荐三种方式：
- 用 IDE 自动生成（IntelliJ/Eclipse 都支持勾选字段一键生成）；
- 用 JDK 7+ 的 Objects.hash(field1, field2, ...)，一行搞定，自动处理 null 和混合计算；
- 示例：return Objects.hash(name, age, department);
注意：只包含参与 equals 判断的字段；避免用可变字段（如 ArrayList.size()）、未初始化的 ID 或原始浮点数（要用 Double.doubleToLongBits(x) 统一处理）。
常见踩坑点
这些错误会让对象在 HashMap 中“消失”或行为异常：
- 字段参与了 equals 比较，却没放进 hashCode 计算；
- 用了可变字段（比如用 List 的 size 当依据，后续 add 后 size 变，hashCode 就变）；
- 字符串忽略大小写比较（equals 用 toLowerCase），但 hashCode 没同步处理（得用 str.toLowerCase().hashCode()）；
- 浮点字段直接调用 hashCode()，导致 0.0 和 -0.0 虽 equals 为 true，但默认 hashCode 不同。
