HashSet 不适合千万级以上数据去重，因内存开销大、GC压力高、易OOM；应优先用布隆过滤器初筛，再结合磁盘归并或Redis/Spark等分布式方案。
HashSet 本身不适合直接处理千万级以上的数据去重，不是因为它“不能去重”，而是内存开销和运行稳定性会迅速失控。关键不在“怎么用”，而在“什么情况下不该用”以及“怎么用才安全”。
先看为什么大数据量下 HashSet 容易翻车
HashSet 底层是 HashMap
- 每存一个字符串（比如 UUID），JVM 不仅要存内容，还要额外分配对象头、引用指针、数组桶结构等——实际内存占用通常是原始文本的 3–5 倍
- 哈希冲突多、扩容频繁时，链表或红黑树结构会放大 GC 压力，甚至触发长时间 Stop-The-World
- 没重写 hashCode() 和 equals() 的自定义对象，add() 永远返回 true，根本不去重
真要硬上 HashSet，必须做这四件事
如果数据量在百万级、重复率高、内存可控（比如堆设到 4G+），可优化使用：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 预估容量，避免扩容：构造时传入初始容量，按预期唯一数 ÷ 0.75 计算。例如预计 200 万不重复 ID，写 new HashSet(2666667)
- 分批 add，别一次性addAll()：从数据库或文件流式读取，每 10 万条 add 一次，期间检查 size() 和 GC 日志
- 字符串注意 intern() 风险：UUID、长随机字符串调用 intern() 会进常量池，反而加剧 Full GC，一般不建议
- 确认 equals/hashCode 正确性：字段含 null 时用 Objects.equals；Lombok 用户加 @EqualsAndHashCode(include = {"id"})
当数据量超千万，该换方案了
硬塞 HashSet 很可能 OOM。更合理的路径是分级处理：
- 初筛用布隆过滤器（BloomFilter）：内存占用极小（比如 1 亿条 UUID 只需约 120MB），支持快速判断“大概率没见过”，但有误判率（只报存在，不报不存在）
- 落地再归并去重：把数据分块排序后写磁盘，再逐块读取比对前一条，空间复杂度降到 O(1)，适合离线统计
- 外挂存储系统：Redis 的 SET 或 BF.ADD 做实时去重；Spark + Parquet 做分布式去重；或者用 ClickHouse 的 uniqState/uniqMerge
按场景选替代写法（Java 内置可用）
不换技术栈，也能降风险：
- 只要去重不要顺序：仍用 HashSet，但配合 try-with-resources 流式读取 + 显式 gc() 监控
- 要保持插入顺序：改用 LinkedHashSet，代价是多维护一个双向链表，内存略增
- 需边查边去重（如日志行处理）：用 Map
手动控制，key 是待判重字段，value 固定 true，比 Set 更直观 - 只按某字段去重（如 email）：用 Collectors.toMap(user -> user.getEmail(), u -> u, (u1, u2) -> u1)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
