HashSet不适用于海量数据秒级去重，因其必须将所有元素加载进JVM堆内存，易触发OOM和频繁GC，哈希冲突与扩容导致性能退化，属单机内存硬限制。
HashSet 本身不适合大数据量去重，因为它必须把所有元素完整加载进 JVM 堆内存。一旦数据量超过单机内存承载能力（通常千万级字符串以上），就极容易触发 OutOfMemoryError，不是调优能解决的硬限制。
真正可行的做法是：不强行用 HashSet，而是换掉它。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
明确 HashSet 的内存瓶颈在哪
- 每个字符串对象在堆中不只是存字符内容，还包括对象头、引用字段、char[] 数组等，实际内存占用常为原始文本的 3–4 倍
- 默认初始容量是 16，数据量大时频繁扩容 + rehash，会临时占用双倍内存
- 哈希冲突多（比如大量 UUID 前缀相同）会导致链表或红黑树深度增加，GC 压力陡升
数据仍在 Java 进程内处理？可尝试的收敛方案
-
预估唯一值数量，初始化时指定合理容量：
new HashSet<>(expectedUniqueCount / 0.75f)，避免扩容抖动 -
流式添加，不一次性
addAll()：从文件或数据库分批读取，每批 add 后检查size()和 GC 日志 -
确保
hashCode()和equals()正确实现：自定义类必须只基于判重字段（如 id），且逻辑一致；字符串可直接用，不用额外处理 -
用
add()返回值判断，别先contains()再add()：少一次哈希查找，降低开销
数据量明显超内存？该切换技术栈了
-
SQL 层前置去重：
SELECT COUNT(DISTINCT user_id) FROM logs WHERE dt = '2026-09-14'，交给 Doris、StarRocks 或 PostgreSQL 并行聚合 -
离线批处理用 Spark：
df.dropDuplicates("id")自动 shuffle + reduce，不依赖单机内存 - 实时流去重用 Flink：配合 RocksDBStateBackend 存状态，支持 checkpoint 和故障恢复
- 仅需存在性判断（不要求返回全部唯一值）：布隆过滤器（BloomFilter）1GB 内存可支撑百亿级判重，误判率可控
不复杂但容易忽略：去重目标决定技术选型。要的是“唯一值集合”，才考虑内存结构；要的是“唯一数量”或“是否见过”，就该绕过 HashSet。
