hashset不适合千万级字符串去重，因内存消耗过大；应依数据规模选布隆过滤器、外部排序或分布式引擎等替代方案。

HashSet 不适合直接处理大量数据的排重任务，尤其当字符串量达到千万级或原始文本超几百 MB 时，内存消耗会远超预期——这不是写法问题，而是其底层哈希表结构决定的硬限制。真正有效的做法不是“调优 HashSet”，而是根据数据规模和业务需求，选择更匹配的技术路径。

先判断是否真需要 HashSet

如果去重目标是几百万以内的短字符串（如日志 ID、设备码、短 Token），且全部能常驻内存，HashSet 仍是最快最简方案。关键操作如下：

• 预设初始容量：new HashSet(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 级，应放弃单机堆内方案：

• 布隆过滤器（BloomFilter）：内存极小（如 1 亿条用 128 MB），支持超大数据集初筛，但有误判率（只报“可能存在”）
• 外部排序 + 归并去重：分块排序后流式合并，边读边比前一个，空间复杂度接近 O(1)
• 分布式引擎：Spark 的 dropDuplicates() 或 Flink 的状态后端（RocksDB），自动分片、容错、可 checkpoint
• Redis SET/BF.ADD：适合实时流式判断“是否见过”，但要注意网络延迟与序列化成本

别被“有序”误导

有人想用 LinkedHashSet 保序，但它底层仍是哈希表 + 双向链表，每个元素多存两个指针，内存比 HashSet 更高，且不减少字符串对象本身的开销。

• 如果业务只要求“去重”，顺序无关，就坚持用 HashSet
• 如果必须保持插入顺序，且数据量可控，再选 LinkedHashSet
• 顺序维护带来的是常数级开销，对内存无实质改善

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南