HashSet去重依赖hashCode与equals协同：先用hashCode定位桶，再用equals精确比对；哈希冲突不可避免，但只要遵守契约（equals相等则hashCode必等），去重逻辑仍正确。
Java 中 HashSet 的去重依赖 hashCode 和 equals 协同工作，而哈希冲突（即不同对象算出相同 hashCode）本身是正常且不可避免的。关键不在于“消除”冲突，而在于如何让冲突不影响去重逻辑的正确性。
hashCode 冲突是设计允许的，不是 bug
Java 的 hashCode 返回的是 32 位 int 值，而实际对象数量可能远超 2³²，所以冲突必然存在。JDK 并不要求 hashCode 唯一，只要求：
• 如果 x.equals(y) 为 true，那么 x.hashCode() == y.hashCode() 必须成立；
• 反过来不强制——相同 hashCode 的对象，equals 可以返回 false。
这正是 HashSet 容忍冲突的基础：先用 hashCode 快速定位桶（bucket），再用 equals 精确比对。
去重失效的真正原因通常是契约被破坏
常见错误场景包括：
• 只重写了 equals，没重写 hashCode → 两个逻辑相等的对象 hashCode 不同 → 被放进不同桶，HashSet 认为它们不重复；
• 重写 hashCode 时用了可变字段（比如 name、age），之后修改了字段值 → 对象在 HashSet 中的位置与当前 hashCode 不匹配 → contains 或 remove 失败；
• hashCode 实现不合理（如始终返回固定值 1），导致所有对象挤进同一个桶 → 性能退化为 O(n)，但功能仍正确（靠 equals 最终兜底）。
解决冲突影响的核心做法
• 自定义类必须同时重写 hashCode 和 equals，且逻辑一致（通常用相同字段参与计算）；
• 参与 hashCode 计算的字段必须是不可变的（或至少在对象加入 HashSet 后不再修改）；
• 推荐使用 IDE 自动生成（如 IntelliJ 的 Alt+Insert → “hashCode and equals”），它默认用 31 作为乘数，兼顾分布与效率；
• 若业务需要运行时修改对象状态，考虑改用 Map
Java 底层如何应对大量冲突
HashSet 底层复用 HashMap，其处理冲突的机制是：
• 默认采用 链地址法：每个桶是一个 Node 链表，冲突元素依次挂载；
• 当链表长度 ≥ 8 且 table 长度 ≥ 64 时，自动转为 红黑树，查找复杂度从 O(n) 优化到 O(log n)；
• 扩容机制（负载因子 0.75）也会动态减少单桶元素数量，缓解冲突压力。
