hashset去重有显著空间开销：100万个32字符字符串本体占90–100mb，hashmap底层额外增加1.5–2倍内存，扩容与哈希冲突进一步推高占用，需预估容量并优化hashcode。
哈希去重不是零成本操作，空间开销必须提前算清楚。尤其在处理百万级以上数据时，盲目 new HashSet() 很容易触发频繁扩容、GC 压力飙升，甚至 OOM。关键不在于“能不能去重”，而在于“用多少内存去重才合理”。
一、先算原始数据体积，再叠加结构开销
别只盯着字符串或数字本身。例如：100 万个长度为 32 的 ASCII 字符串，在 Java 中实际占用远不止 32MB：
- 每个 String 对象含 12 字节对象头 + 4 字节 char[] 引用 + 4 字节 count/offset/hash 等字段（JDK8+）；
- char[] 数组本身还有 12 字节数组头 + 实际内容（32 字节 × 2 = 64 字节 UTF-16）；
- 加上 8 字节对齐填充，单个字符串常占 88–96 字节；
- 100 万条 ≈ 90–100 MB 原始堆开销。
这还只是数据本体——HashSet 的底层 HashMap 会在此基础上额外增加至少 1.5–2 倍空间。
二、HashMap 底层容量与扩容公式
HashSet 内部用 HashMap 存 key，value 是共享的 PRESENT 对象。真正吃内存的是哈希桶数组和 Node 节点：
- 默认初始容量 16，加载因子 0.75 → 插入第 13 个元素就扩容；
- 扩容后容量翻倍（16→32→64…），旧数组全量 rehash，临时峰值内存可能达稳定值的 2.5 倍；
- 预估容量公式：initialCapacity = (expectedSize / 0.75f) + 1；
- 比如预计存 80 万个唯一元素，应写 new HashSet(1_066_667)，而非默认构造。
三、节点与哈希冲突带来的隐性膨胀
即使容量设对了，hashCode 分布差也会悄悄抬高内存：
- 每个 Node 对象（链表节点）含 hash、key、next 三个字段，在 64 位 JVM + 开启指针压缩下约 24 字节；
- 若某桶链表长 10，光这一个桶就多占 240 字节，还拖慢查询；
- 自定义类务必重写 hashCode()，推荐用 Objects.hash(f1, f2, f3)，避免简单拼接或取模导致聚集；
- 字符串天然哈希质量较好，但大量前缀相同（如 URL /api/v1/xxx）仍易冲突，可考虑截取后缀或加盐再哈希。
四、超大规模场景下的替代路径
当预期唯一元素超 500 万，且内存敏感时，需跳出 HashSet 思维：
- 布隆过滤器 + 落盘校验：用 12MB 内存管理 1 亿 URL，误判率控制在 0.1%，重复判定由 DB 或文件二次确认；
- 排序后流式去重：外排 + 归并，内存峰值仅 O(1)，适合离线 ETL；
- HyperLogLog 估算基数：不存元素，只估“有多少不同值”，1.5KB 支持 2^64 级别，误差
- 分片哈希 + 多级缓存：按 key 分片到多个小 HashSet，配合 LRU 控制单个实例大小，避免单点膨胀。
