优化 HashSet 内存占用需从初始化、使用方式、数据结构选择三层面干预：预设合理初始容量（如 new HashSet(256)）和负载因子（≤0.85），避免频繁扩容；减少包装类与冗余字段，慎用 toArray()；超大规模或特定场景下改用 BitSet、布隆过滤器或 IntSet 等更省内存方案。
优化 HashSet 的内存占用，关键在于减少冗余对象、控制底层哈希表容量、避免隐式开销。它不是单纯“删代码”，而是从初始化、使用方式、数据结构选择三个层面精准干预。
合理设置初始容量和负载因子
HashSet 底层是 HashMap，而 HashMap 使用数组 + 链表/红黑树存储。默认初始容量为 16、负载因子 0.75，意味着插入第 13 个元素（16 × 0.75）就会触发扩容——数组翻倍、所有元素 rehash，不仅耗时，还临时多占一倍内存。
- 若已知元素数量（比如读取固定配置项约 200 条），直接指定容量：
new HashSet(256)（向上取 2 的幂，如 256） - 若集合长期只读或写少读多，可略调高负载因子（如
0.85f），延缓扩容；但别超过 0.9，否则哈希冲突激增，链表变长，反而增加内存碎片和查找开销
避免无意义的包装与冗余引用
HashSet 存的是对象引用，每个元素本身及其哈希桶结构都占空间。常见浪费点：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用
Integer、String等包装类存大量小整数或短字符串？考虑是否可用int[]+ 手动去重逻辑，或引入IntSet（如 Eclipse Collections 或 Trove 库），节省装箱开销和对象头内存 - 集合中存的是自定义对象？检查字段：是否含未使用的缓存字段、大字节数组、未清理的监听器引用？这些都会被一起保留在堆中
- 操作完成后及时置空引用：
set = null;或让其脱离作用域，帮助 GC 尽快回收整个哈希表数组
慎用 toArray() 生成新数组
set.toArray()（无参）会反射创建新数组，额外分配内存；即使传 new String[0]，JVM 仍需运行时推导类型并新建数组。
立即学习“Java免费学习笔记（深入）”；
- 如需转数组且已知大小，用预分配方式：
String[] arr = set.toArray(new String[set.size()]);—— 复用原数组，零额外分配 - 如果只是遍历，优先用增强 for 或迭代器，避免生成中间数组
- 若后续无需修改数组，且集合本身生命周期短，可考虑用
Arrays.asList(...).stream().collect(Collectors.toSet())反向控制，但注意这会新建集合，仅适合小数据场景
根据场景换更省内存的替代方案
并非所有“去重”都必须用 HashSet：
- 元素范围固定且有限（如状态码 0–99）：用
boolean[]或BitSet，一个布尔值仅占 1 字节（实际 JVM 可能优化），BitSet更省（1 bit/元素） - 数据量极大且允许近似去重：用布隆过滤器（Bloom Filter），内存开销极低，但有误判率
- 需要排序+去重：TreeSet 虽然内存略高（红黑树节点比哈希桶多指针），但省去了额外排序步骤，整体可能更优
