HashSet 不保证 hashCode 一致，责任在自定义类实现者；一致性指同一对象在状态不变时多次调用 hashCode() 必须返回相同值，否则导致对象“丢失”；应仅用不可变字段计算哈希，推荐 Objects.hash() 并验证。
HashSet 本身不保证、也不干预对象的 hashCode 是否一致。它只是依赖你提供的 hashCode() 方法返回值是否满足一致性契约——这个责任完全在自定义类的实现者身上。
关键在于：一致性不是 HashSet 给的，是你写的 hashCode() 必须做到的。
什么是一致性？
对同一个对象，在其用于 equals() 比较的字段没有发生变化的前提下，无论调用多少次 hashCode()，都必须返回完全相同的整数值。
比如：
立即学习“Java免费学习笔记（深入）”；
Person p = new Person("Alice", 25);
int h1 = p.hashCode();
int h2 = p.hashCode(); // 必须等于 h1即使 JVM 重启、程序重跑，只要对象状态一样（比如 name 和 age 没变），结果也应稳定（实践中基本成立）。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
为什么一致性对 HashSet 至关重要？
HashSet 底层用 HashMap 存储，插入后会把对象“固定”在某个桶（bucket）里。
如果之后你修改了影响 hashCode() 的字段（比如 p.setName("Bob")），而 hashCode() 又没做缓存或校验：
- 对象仍留在原来的桶中；
-
contains(p)或remove(p)会去新哈希值对应的桶里找——根本找不到； - 表现就是：对象“丢了”，既查不到，也删不掉。
这并非 HashSet 的 bug，而是你破坏了一致性契约导致的逻辑断裂。
怎么真正保障一致性？
只用不可变字段参与
hashCode()计算
比如final String name; final int age;—— 构造后无法修改，天然保一致。避免使用可变字段（如普通 setter 修改的属性）
若业务上必须可变，请不要把它放进hashCode()；否则要么同步更新桶位置（HashSet 不支持），要么接受“冻结哈希值”的事实。用
Objects.hash(...)安全生成
它自动处理 null，并基于传入字段稳定计算，比手写31 * a + b更可靠。-
不可变类可缓存哈希值（进阶优化）
private final int hashCode; public Person(String name, int age) { this.name = name; this.age = age; this.hashCode = Objects.hash(name, age); // 一次算好，永不改变 } @Override public int hashCode() { return hashCode; } -
数组、浮点等特殊类型要正确处理
- 数组字段 → 用
Arrays.hashCode(arr)，别用arr.hashCode()（那是引用哈希） -
float/double→ 先转位模式：Float.floatToIntBits(f)，防 NaN 和 ±0 异常
- 数组字段 → 用
验证一致性的小方法
写个简单测试：
Person p = new Person("Tom", 30);
Set<Integer> hashes = new HashSet<>();
for (int i = 0; i < 100; i++) {
hashes.add(p.hashCode());
}
System.out.println(hashes.size()); // 应该输出 1如果输出大于 1，说明你的 hashCode() 在同一对象上返回了不同值——立刻检查是否误用了可变状态或随机/时间相关逻辑。
不复杂但容易忽略
