hashCode 决定对象在哈希集合中的存储位置，影响查找、插入、删除的平均时间复杂度；必须与 equals 保持一致，否则导致哈希集合行为异常；好 hashCode 需满足快、散、稳三特征。
hashCode 是 Java 中决定对象在哈希集合（如 HashMap、HashSet、ConcurrentHashMap）中存放位置的关键依据。它不只影响“能不能存进去”，更直接决定查找、插入、删除操作的平均时间复杂度——理想情况下是 O(1)，而一旦 hashCode 设计不当，可能退化为 O(n)。
hashCode 决定桶（bucket）位置
哈希集合底层基于数组 + 链表/红黑树实现。当调用 put 或 add 时，JVM 先调用对象的 hashCode() 方法，再对结果做扰动运算（如 HashMap 中的 (h = key.hashCode()) ^ (h >>> 16)），最后与数组长度减一做位运算（index = hash & (table.length - 1)）来定位桶下标。
- 如果两个对象逻辑相等（equals() 返回 true），但 hashCode 不同 → 可能被放进不同桶 → HashSet 误判为不同元素，或 HashMap 无法命中已存在的键
- 如果大量对象 hashCode 相同（哈希碰撞严重）→ 都挤进同一个桶 → 链表变长，甚至触发树化 → 查找从 O(1) 退化为 O(log n) 或 O(n)
重写 equals 时必须重写 hashCode
这是 Java 的契约要求：若 a.equals(b) 为 true，则 a.hashCode() 必须等于 b.hashCode()。违反该规则会导致哈希集合行为异常，且难以排查。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- IDE（如 IntelliJ）通常提供一键生成 equals/hashCode 功能，推荐使用，避免手写疏漏
- 字段选择要一致：equals 比较哪些字段，hashCode 就应基于哪些字段计算（常用 Objects.hash(field1, field2, ...)
- 不可变类（如 String、LocalDate）天然适合做 key；可变对象作 key 时，若修改了参与 hashCode 计算的字段，可能导致元素“丢失”（再也 get 不到）
好 hashCode 的三个特征
高效哈希函数不是越复杂越好，而是追求：快、散、稳。
立即学习“Java免费学习笔记（深入）”；
- 快：计算开销小，避免大循环、IO、复杂数学运算
- 散：相同类型的不同实例，尽量产生差异大的整数，降低碰撞概率（如 String 的 hashCode 使用 31 * h + char[i]，利用质数减少规律性）
- 稳：只要对象参与计算的字段不变，多次调用 hashCode 必须返回相同值（即使跨 JVM 实例、跨程序重启）
常见性能陷阱与优化提示
实际开发中，几个看似微小的设计可能悄悄拖垮哈希集合性能：
- 用 new Object() 作 key → 每次 hashCode 都不同（默认实现是内存地址相关）→ 完全无法复用，等价于每次新建一个唯一 key
- 自定义类只重写了 equals 但忘了 hashCode → 所有实例默认 hashCode 来自 Object，很可能都不同 → 即使逻辑相等也无法查到
- 在 hashCode 中调用耗时方法（如 toString().length()、数据库查询）→ 每次 put/get 都触发，性能雪崩
- 数组、List 等容器类作为 key 时，注意其默认 hashCode 行为（ArrayList 会遍历元素计算；而 Arrays.asList 返回的 List 不一定重写 hashCode，需确认）
