HashSet无法支撑海量数据秒级去重，因其依赖单机内存、易触发OOM和GC，哈希冲突与扩容会导致性能退化。
HashSet 去重为什么不能用于“海量数据”
直接说结论：HashSet 无法真正支撑“海量数据”的秒级去重——它只适合单机内存可容纳的数据量（通常在千万级以内，取决于元素大小和可用堆内存）。一旦数据量超过几百 MB 或上亿条记录，HashSet 会触发频繁 GC、OOM，或因哈希冲突激增导致 put() 和 contains() 退化为 O(n)。这不是写法问题，而是其底层结构决定的硬限制。
HashSet 的实际工作原理与性能拐点
HashSet 底层是 HashMap，插入时先计算 key 的 hashCode()，再取模定位桶位置；若发生哈希冲突（不同对象算出相同 hash），则用链表或红黑树存储。这意味着：
- 所有元素必须能完整加载进 JVM 堆内存，无磁盘/网络交换能力
- 哈希函数质量直接影响桶分布——自定义对象未重写
hashCode()和equals()会导致全部元素挤进同一个桶 - 当负载因子（默认 0.75）被突破，会触发扩容（rehash），此时需重新计算全部已有元素的 hash 并迁移，暂停写入且耗时突增
- 实测：1 亿个
String（平均长度 20 字节）在 8GB 堆下，HashSet构建耗时 > 30 秒，内存占用超 6GB，已不可控
什么情况下还能用 HashSet？明确适用边界
如果你的“海量”其实是“单机可处理的中等规模”，比如日志 ID、用户 session token 等短字符串，总量在 1000 万以内，那么 HashSet 仍是最快最简方案。关键操作如下：
Set<String> seen = new HashSet<>(10_000_000); // 预设初始容量，避免扩容
for (String id : inputIds) {
if (seen.add(id)) { // add() 返回 true 表示新增成功（即首次出现）
processUnique(id);
}
}
注意点：
- 务必预设初始容量（如
new HashSet(expectedSize)），否则默认 16 容量会触发多次 rehash - 若元素是自定义对象，必须重写
hashCode()和equals()，且两者逻辑一致 - 不要用
contains()+add()两步判断，直接用add()的返回值，少一次查找 - 不建议在多线程环境下直接共享
HashSet，应改用ConcurrentHashMap.newKeySet()
真正的海量场景该换什么？不是升级，是换范式
当数据量达亿级、TB 级，或需持续流式去重时，HashSet 必须让位。替代方案不是“优化它”，而是切换技术栈：
- 实时流：用
Flink的KeyedProcessFunction+ 状态后端（RocksDB），支持 checkpoint 和 exactly-once - 批处理：Spark 的
dropDuplicates()或 SQLDISTINCT，自动分片 + shuffle 去重 - 存在性判重（不要求保留原始数据）：布隆过滤器（
BloomFilter）或 RedisBloom，空间压缩百倍，但有误判率 - 整数范围有限（如用户 ID 是 0~2^32）：BitMap 或 RoaringBitmap，内存占用可压到 KB~MB 级
最容易被忽略的一点：所谓“秒级”，本质是接受一定误差或延迟。纯精确、全量、低延迟、高吞吐四者不可兼得——选哪三个，决定了你该用 HashSet 还是立刻切走。
