HashSet不适合千万级字符串去重，因内存消耗过大；应依数据规模选布隆过滤器、外部排序或分布式引擎等替代方案。
HashSet 不适合直接处理大量数据的排重任务，尤其当字符串量达到千万级或原始文本超几百 MB 时，内存消耗会远超预期——这不是写法问题，而是其底层哈希表结构决定的硬限制。真正有效的做法不是“调优 HashSet”，而是根据数据规模和业务需求，选择更匹配的技术路径。
先判断是否真需要 HashSet
如果去重目标是几百万以内的短字符串（如日志 ID、设备码、短 Token），且全部能常驻内存，HashSet 仍是最快最简方案。关键操作如下：
- 预设初始容量：new HashSet<String>(expectedSize / 0.75f)，避免扩容时反复 rehash 和双倍内存占用
- 用 add() 返回值 判断是否新增，不要先 contains() 再 add()，省一次查找
- 确保字符串来源稳定，避免大量重复创建新对象（如循环中 new String(...)）
字符串本身才是内存大头
一个长度为 32 的 ASCII 字符串，在 JVM 中实际占约 64–80 字节：对象头 + char[] 数组 + 引用指针等。1000 万个这样的字符串，仅对象层面就超 600 MB。HashSet 的桶数组、Node 节点等只是额外开销。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 不要盲目调用 String.intern()，它会把字符串塞进 Metaspace，反而加重 GC 压力
- 若字符串来自固定配置或枚举，JVM 可能已自动共享；可抽样检查 == 是否成立
- 极端场景下可考虑用 byte[] 或 CharBuffer 替代 String 对象，但需自行管理比较逻辑
数据超限就该换技术栈
当唯一字符串预计超 500 万，或原始数据达 GB 级，应放弃单机堆内方案：
立即学习“Java免费学习笔记（深入）”；
- 布隆过滤器（BloomFilter）：内存极小（如 1 亿条用 128 MB），支持超大数据集初筛，但有误判率（只报“可能存在”）
- 外部排序 + 归并去重：分块排序后流式合并，边读边比前一个，空间复杂度接近 O(1)
- 分布式引擎：Spark 的 dropDuplicates() 或 Flink 的状态后端（RocksDB），自动分片、容错、可 checkpoint
- Redis SET/BF.ADD：适合实时流式判断“是否见过”，但要注意网络延迟与序列化成本
别被“有序”误导
有人想用 LinkedHashSet 保序，但它底层仍是哈希表 + 双向链表，每个元素多存两个指针，内存比 HashSet 更高，且不减少字符串对象本身的开销。
- 如果业务只要求“去重”，顺序无关，就坚持用 HashSet
- 如果必须保持插入顺序，且数据量可控，再选 LinkedHashSet
- 顺序维护带来的是常数级开销，对内存无实质改善
