HashSet去重关键在hashCode()与equals()协同：先用hashCode()定位桶，再用equals()精确比对；二者必须同时重写且逻辑一致，否则去重失效。
直接用 HashSet 实现高效去重，关键不在“怎么写 add”，而在于“为什么能去重”以及“怎么避免去重失效”。它快，是因为底层复用了 HashMap 的哈希表结构；它准，却完全依赖你写的 hashCode 和 equals 方法是否合规。不搞懂这两点，哪怕代码跑通了，上线也可能悄悄漏掉重复数据。
HashSet 去重靠的是 HashMap 的 key 唯一性
HashSet 本身不存数据，它只是把每个元素当 key，往内部的 HashMap<E, Object> 里塞，value 统一用一个空对象 PRESENT 占位。所以：
- add(e) 实际执行的是
map.put(e, PRESENT) - HashMap 要求 key 不可重复——只要两个对象的 hashCode 相同且 equals 返回 true，就认为是同一个 key，新值不会覆盖旧 key，但 put() 会返回旧 value（即 PRESENT），于是 add() 就返回 false
- 这意味着：HashSet 的去重能力，100% 继承自 HashMap 的 key 判断逻辑
必须同时重写 hashCode 和 equals，缺一不可
只重写 equals，或只重写 hashCode，都会导致去重失败。原因很直接：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- hashCode 决定“去哪个桶”：两个逻辑相等的对象，如果 hashCode 不同，会被分到不同桶里，equals 根本不会被调用
- equals 决定“是不是同一个”：只有落在同一个桶里的对象，才会逐个调用 equals 比较；如果 equals 写错（比如只比 id 却忽略 name 的语义一致性），相同业务含义的对象可能被当成不同元素
- 正确做法：用所有参与“逻辑相等”判断的字段，一起生成 hashCode，并在 equals 中做完全一致的字段比较
避免把可变对象放进 HashSet
一旦对象加入 HashSet 后修改了影响 hashCode 或 equals 的字段，就会出问题：
立即学习“Java免费学习笔记（深入）”；
- 原对象的哈希值变了，但它还留在旧桶里；后续调用 contains() 时，会按新哈希值去找桶，结果找不到
- 更糟的是，它可能和另一个新对象发生哈希冲突，但 equals 又不匹配，导致集合中出现“本该被去重”的重复项
- 解决方案：尽量用不可变对象（如 String、Integer、LocalDate）；若必须用可变类，确保加入 HashSet 后不再修改关键字段，或改用其他结构（如 TreeSet + 自定义 Comparator）
注意 null 和线程安全的边界情况
HashSet 允许存一个 null 元素，因为 HashMap 支持 key 为 null（它被固定放在数组下标 0 的位置）。但要注意：
- 多个
null连续 add，只会保留一个——这是符合预期的 - HashSet 是非线程安全的。多线程并发 add/contains，可能出现数据丢失或 size 不准确；如需并发安全，可用
Collections.synchronizedSet(new HashSet())，或更优的ConcurrentHashMap.newKeySet()（JDK 8+） - 不要依赖迭代顺序：HashSet 不保证顺序，遍历时顺序可能每次都不一样；需要顺序请换 LinkedHashSet
