hashset内存优化关键在于预设合理初始容量（initialcapacity = ⌈n/0.75⌉）、避免包装类开销、精简hashcode/equals实现，并在海量场景下考虑布隆过滤器等替代结构。
合理设置初始容量与负载因子
默认 HashSet 构造函数（new HashSet()）使用 16 的初始容量和 0.75 的负载因子，意味着插入第 13 个元素就可能触发扩容。频繁扩容会反复创建新数组、迁移旧节点，不仅耗时，还造成老数组暂时无法回收，加剧 GC 压力。
✅ 正确做法是预估元素总数 n，按公式向上取整计算初始容量：
initialCapacity = (int) Math.ceil(n / 0.75)
例如预计存 100 万个字符串，应设为 new HashSet(1_333_334)；若用 0.8 作为负载因子（更紧凑），可进一步微调。
⚠️ 注意：容量必须是 2 的幂次（JDK 内部会自动调整），但你传入的值会被内部 round up 到最近的 2 的幂，所以直接给大一点的整数更稳妥。
避免包装类与冗余对象开销
存储基本类型时，别用 Integer、Long、Boolean 等包装类——它们每个实例都带对象头、类指针、字段等额外开销（通常 16~24 字节），远超本身 4 或 8 字节的值。
✅ 替代方案：
- 大量整数去重 → 用 IntSet（如 Eclipse Collections 的
IntHashSet）或自定义位图/有序数组+二分 - 大量字符串 ID → 检查是否可截断、归一化（如统一小写、去空格）、或转为 long（如时间戳+序列号编码）再用 LongHashSet
- 自定义对象 → 确保 hashCode() 计算轻量（避免深字段遍历、正则、IO），且不依赖易变状态
精简 hashCode 和 equals 实现
低效的 hashCode() 不仅拖慢单次插入，还会因分布不均导致哈希桶严重倾斜——某些链表/红黑树极长，其他桶为空，既浪费内存又降低查询效率。
✅ 遵循原则：
- 只参与影响业务唯一性的字段（比如 User 去重只需 id，不用 name + phone + avatarUrl）
- 优先用 Objects.hash(id) 而非手写多个字段异或（易出错且未必更优）
- 避免在 hashCode() 中调用 toString()、JSON 序列化、数据库查询等重型操作
- 确保 equals() 和 hashCode() 逻辑严格一致，否则去重失效
考虑替代结构：真海量时绕过 HashSet
当元素量级达百万以上，且内存敏感（如鸿蒙/Android 客户端、嵌入式 Java），HashSet 的线性内存增长（≈ 元素数 × 32~48 字节）可能成为瓶颈。
✅ 可评估的替代方案：
- 布隆过滤器（Bloom Filter）：固定内存（如 1MB 位数组支持千万级元素，误判率
- Roaring Bitmap：对整数 ID 高度压缩，比 HashSet 节省 5~10 倍内存，支持交并差运算
- 外部存储 + 缓存：高频查询用 Caffeine 缓存热点 ID，全量去重走 Redis Set 或本地 LevelDB
这些不是取代 HashSet，而是在它“力不从心”的边界上，提供更经济的选择。
