hashset去重高效但需合理使用：必须重写hashcode()和equals()，预设初始容量避免频繁扩容，亿级数据应换布隆过滤器等轻量方案。
HashSet 本身已是海量数据去重的高效选择，关键在合理使用和规避常见陷阱。它底层基于 HashMap（JDK 8+ 还有红黑树优化），平均时间复杂度 O(1) 查找/插入，远优于 List 的 O(n)。但“快”不等于“无脑用”，真正影响海量场景性能的是对象设计、内存控制与使用方式。
确保元素正确重写 hashCode() 和 equals()
这是 HashSet 正常工作的前提。如果自定义对象（如 User、LogEntry）作为元素，未重写这两个方法，所有实例默认散列到不同桶，equals 也永远返回 false——结果就是“看似没重复，实际全存进去了”，既浪费内存又查不准。
- 用 IDE 自动生成（如 IntelliJ 的
Alt+Insert → equals() and hashCode()），字段选全且一致 - 避免在 hashCode() 中使用可变字段（如 status、updateTime），否则对象加入 Set 后修改这些字段，会导致再也找不到它
- 字符串、数字、LocalDateTime 等 JDK 不可变类可直接用，无需额外处理
预估容量 + 设置初始容量，避免频繁扩容
HashSet 默认初始容量 16，负载因子 0.75。当元素数超过 capacity × 0.75 时触发扩容（rehash），整个内部数组重建、所有元素重新散列——海量数据下一次扩容可能耗时数百毫秒甚至秒级。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 如果预估要存 1000 万个 ID，设初始容量为
new HashSet(12_500_000)（1000万 ÷ 0.75 ≈ 1333万，向上取 2 的幂得 16777216；保守点取 1250 万即可） - 用
HashSet(int initialCapacity)构造，别依赖默认值 - 扩容是静默发生的，可通过 JVM 参数
-XX:+PrintGCDetails或 JFR 观察是否频繁 rehash
用更轻量的替代方案（真·海量时）
当数据量达亿级、内存受限或只需“是否存在”而非存储对象本身时，HashSet 可能不是最优解：
- Bloom Filter（布隆过滤器）：极省内存（例如 1 亿条数据仅需 ~120MB），支持超快存在性判断，但有极小误判率（可调），且不支持删除。适合前置过滤（如“这个订单号之前见过吗？”）
-
LongHashSet / IntHashSet（来自 Trove 或 Eclipse Collections）：跳过装箱拆箱，存基本类型更省内存、更快。比如存 1000 万个 long ID，比
HashSet<long></long>节省约 40% 内存 -
分片 + 文件/Redis 外存：单机内存扛不住时，按 hash(key) % N 分片，每片用独立 HashSet；或把去重状态下沉到 Redis 的 Set（
SADD原子性天然防重）
排查重复项的实际操作建议
不是只靠 HashSet.add() 返回 false 就完事，要构建可观测、可验证的流程：
- 加监控：统计每秒新增数、当前 size、add() 返回 false 的频次（即真实重复数）
- 抽样记录重复项（如用 ConcurrentHashMap 计数），便于定位源头是数据问题还是逻辑 bug
- 避免在循环中反复 new HashSet —— 复用实例，或用 try-with-resources 管理（若配合 Stream.collect(Collectors.toSet()) 则自动复用）
- 注意线程安全：HashSet 非线程安全。并发写必须用
Collections.synchronizedSet()或ConcurrentHashMap.newKeySet()（JDK 8+，性能更好）
不复杂但容易忽略。核心就三点：对象契约写对、容量设够、超出单机能力时及时换方案。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
