HashSet不为省内存设计，优势是O(1)去重速度；内存大户是字符串对象本身、Node节点和桶数组；优化关键在于预设容量、减少字符串开销、或改用布隆过滤器等替代方案。
HashSet 本身不是为节省内存设计的，它的优势在去重速度（平均 O(1)），而不是内存紧凑性。当处理大量字符串（比如百万级以上）时，内存占用主要来自三块：字符串对象自身、HashSet 内部 HashMap 的 Node 节点、以及哈希桶数组。想提升内存使用效率，关键不是“调优 HashSet”，而是“绕过它的内存瓶颈”。
预设合理初始容量，避免扩容抖动
默认 HashSet 初始容量是 16，负载因子 0.75。如果最终要存 500 万个唯一字符串，不预设容量会触发多次扩容——每次扩容都要新建数组、rehash 全量元素，临时内存翻倍，GC 压力陡增。
- 按公式计算：预期数量 ÷ 0.75，向上取整。例如预估 500 万唯一值 → new HashSet(6_666_667)
- 若重复率高（比如原始数据 2000 万，但实际唯一仅 200 万），可先抽样统计重复比例，再调整预估值，避免过度预留浪费内存
- 扩容过程不光耗时，还会产生大量短生命周期对象，加重 GC 负担；预设后基本可消除该阶段的内存尖峰
减少字符串对象本身的开销
一个长度为 20 的 ASCII 字符串，在 JVM 中通常占 64–72 字节：对象头 12 字节 + value 引用 4 字节 + char[] 数组（16 字节头 + 40 字节内容）+ padding。1000 万个这样的字符串，光字符串对象就超 600 MB。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 检查是否已复用：相同字面量字符串（如配置项、枚举名）JVM 可能已 intern，无需手动干预
- 避免无意义调用 String.intern()：在大量动态字符串场景下，它会把字符串塞进 Metaspace，反而引发 Metaspace GC 频繁，得不偿失
- 考虑更轻量表示：如业务允许，用 byte[] 替代 String 存储纯 ASCII 内容；或对固定词典类数据，用整数 ID 映射代替原始字符串
评估是否真该用 HashSet
如果目标只是“判断是否见过”，而非“后续还要遍历所有唯一值”，那 HashSet 就过于厚重了。它的每个元素都承载完整对象引用和哈希节点结构。
立即学习“Java免费学习笔记（深入）”；
- 布隆过滤器（Bloom Filter）：内存占用可压缩到 HashSet 的 1/10 甚至更低，支持快速“可能存在”判断，适合前置去重或缓存穿透防护
- 外部排序 + 流式去重：将数据分块写文件、排序、归并，边读边比对相邻行，内存只留常量级缓冲区
- 分布式方案：如用 Redis Set 或 ClickHouse 的 uniqCombined，把压力从 JVM 搬到专用服务
别被 LinkedHashSet 迷惑
它保持插入顺序，但底层仍是 HashMap + 双向链表，每个元素多存两个指针（prev/next），内存比 HashSet 略高。顺序需求 ≠ 内存优化需求。
- 如果业务必须保序，LinkedHashSet 是合理选择，但它不省内存
- 如果只是为了“看着顺眼”而选它，反而增加了不必要的内存和 CPU 开销
