HashSet无法完全避免哈希冲突，但可通过预设容量、正确重写hashCode/equals、利用红黑树降级机制及禁止修改影响hash的字段来控制冲突。
HashSet 本身无法完全避免哈希冲突，但可以通过合理配置和规范编码，显著降低冲突频率、防止其恶化为性能瓶颈。关键不在于“消灭冲突”，而在于让冲突可控、可退化、不拖慢整体操作。
预设足够容量，避开频繁扩容
默认初始容量为16、负载因子0.75，意味着插入第13个元素就可能触发首次扩容。频繁扩容会重新计算所有元素的哈希值并迁移，带来明显开销。
- 若已知大致元素数量（如预计插入5000个对象），显式指定初始容量：
new HashSet(6400)（向上取最接近2的幂，且留出余量） - 容量建议按公式估算：预期元素数 ÷ 0.75，再向上取最近的2的幂（如5000 ÷ 0.75 ≈ 6667 → 取8192）
- 避免使用无参构造后反复 add——尤其在批量导入场景下，扩容可能触发多次（16→32→64→128…）
确保自定义对象正确重写 hashCode() 和 equals()
这是去重失效和隐性冲突恶化的主因：错误实现会导致本该落在同一桶的元素分散到不同桶，或本该分散的却挤进同一个桶，破坏哈希分布均匀性。
- 必须同时重写两个方法，且逻辑一致：equals 返回 true 的对象，hashCode 必须返回相同值
- 优先选用不可变字段（如 id、name）参与 hash 计算，避免用易变字段（如 status、lastModified）
- 推荐用 IDE 自动生成（如 IntelliJ 的 Alt+Insert → equals() and hashCode()），或使用
Objects.hash(field1, field2)简化实现
理解并接受链表→红黑树的自动降级机制
JDK 8+ 中，当某个桶的链表长度 ≥ 8 且哈希表容量 ≥ 64 时，该链表会转为红黑树；当元素减少至 ≤ 6 时又退化回链表。这不是“问题”，而是对冲突的主动优化。
立即学习“Java免费学习笔记（深入）”；
- 无需手动干预树化过程，但可通过监控（如 JFR 或自定义 wrapper）观察是否大量桶长期处于树态——这往往提示 hashCode 分布严重不均
- 若发现某类对象频繁触发树化，应优先检查其 hashCode 实现是否过于简单（如只返回常量、只依赖一个字段等）
- 注意：null 元素单独处理，不参与树化，也不影响其他桶
避免在运行时修改影响 hashCode 的字段
一旦对象被加入 HashSet，就不应修改任何参与 hashCode 计算的字段。否则该对象的哈希值变化，但集合内部仍按旧哈希值定位，导致后续 contains 或 remove 失败——表面看是“查不到”，实则是定位错位引发的逻辑混乱。
- 最佳实践：将参与 hash 的字段声明为
final，从语言层面杜绝误改 - 若业务必须可变，请在修改前先
remove，修改后再add，确保位置同步更新 - 尤其警惕 Lombok 的
@Data自动生成——若字段可变，需确认 @EqualsAndHashCode 正确排除了敏感字段
