HashSet去重以高内存开销为代价，其底层基于HashMap实现，每个元素作为key存储并伴随额外对象头、引用及哈希结构开销，扩容与哈希冲突进一步推高内存占用。
HashSet 去重快，但空间代价不低——它不是“免费”的唯一性保障，而是用内存换时间的典型设计。
底层结构决定空间开销本质
HashSet 本身不存数据，它内部持有一个 HashMap<E, Object>，所有元素都作为 key 存入，value 固定为一个共享的 PRESENT 对象。这意味着：
- 每个去重后的元素，至少占用 HashMap 中一个键值对的空间；
- 哈希表底层是数组 + 链表/红黑树，数组初始容量默认为 16，加载因子 0.75，即插入 12 个元素就会触发扩容；
- 扩容不是简单复制，而是新建两倍大小的数组，并重新哈希所有已有元素，临时内存峰值可能接近原始数据量的 2–3 倍；
- 即使元素内容很小（如一个 10 字节字符串），在 64 位 JVM 中，对象头、引用、对齐填充等开销常使单个元素实际占 32–48 字节以上。
哈希冲突带来隐性空间膨胀
当多个元素哈希值落在同一桶（bucket）时，HashSet 用链表或红黑树组织它们。这会额外引入：
- 链表节点：每个 Node 对象含 next 引用 + key 引用 + 可能的 hash 字段，约 24–32 字节；
- 红黑树节点：比链表多 left/right/parent/color 等字段，节点体积更大，且树结构本身有指针冗余；
- 若 hashCode 分布差（如大量字符串前缀相同），桶中链表/树过长，不仅拖慢性能，也显著抬高内存占用；
- Java 8 规定链表长度 ≥ 8 且数组长度 ≥ 64 才转红黑树，但频繁扩容或低效哈希仍易触发，增加结构开销。
千万级数据下的真实内存压力
以 1000 万个 String（平均长度 20 字符）为例：
- 原始字符串内容约占用 1000 万 × (20×2 + 对象头) ≈ 500–600 MB（UTF-16）；
- HashSet 底层 HashMap 数组最终可能扩至 16384 或更大，加上大量 Node 节点、哈希桶指针、红黑树指针等，总堆内存常达 1.2–1.8 GB；
- 若未预设初始容量（如 new HashSet(12_000_000)），反复扩容会制造大量短期垃圾，加剧 GC 压力；
- 相比排序后去重（如用 TreeSet 或外部归并），HashSet 内存占用通常高出 2–4 倍。
降低空间代价的可行策略
不是不能用 HashSet，而是要用得更清醒：
- 预估数据量，显式指定初始容量：new HashSet<>(expectedSize / 0.75f + 1)；
- 确保自定义类的 hashCode() 尽量均匀，避免人为聚集（例如用 Objects.hash(f1,f2) 比简单拼接更稳妥）；
- 对超大集合，考虑分批处理 + 外部存储（如布隆过滤器初筛 + 文件/DB 落盘）；
- 若顺序不重要且允许少量误判，可先用布隆过滤器过滤再进 HashSet，大幅减少实际入表数据量；
- 字符串场景下，注意 intern() 的风险——虽可复用常量池减少对象数，但可能引发元空间压力或锁竞争。
