HashSet性能优化关键在初始化、对象设计和使用习惯三环节，核心是减少哈希冲突、避免重散列、保证判重稳定。
HashSet 性能优化不是加几个参数就能见效的事，关键在初始化、对象设计和使用习惯三个环节。它底层就是 HashMap，所有优化逻辑都围绕“减少哈希冲突 + 避免重散列 + 保证判重稳定”展开。
预设初始容量与负载因子
默认构造的 HashSet（即 new HashSet()）初始容量是 16，负载因子 0.75，意味着存到第 13 个元素就会触发扩容。频繁扩容会复制整个内部 HashMap 的桶数组，带来明显 GC 和 CPU 开销。
- 如果已知要存约 1000 个用户 ID，用
new HashSet(1024)或更精准地new HashSet((int) Math.ceil(1000 / 0.75)) - 对写多读少、内存敏感的场景，可略调高负载因子（如 0.8f），但别超过 0.9，否则链表/树化概率陡增，反而拖慢查找
- 批量初始化推荐用带 Collection 构造器：
new HashSet(list)，它会按 list.size() 自动算出合适容量，比逐个 add 更高效
确保自定义对象的 hashCode 和 equals 稳定可靠
这是线上最常翻车的点：对象进 Set 后改了参与计算 hashCode 的字段（比如修改了 User.name），再 contains 就找不到——因为 hash 值变了，去错了桶，equals 根本不会被调用。
- 优先把参与判重的字段声明为 final，从源头杜绝可变性风险
- 若必须可变，确保
hashCode()只依赖不可变字段（如 id），或干脆不把该对象放进 HashSet - 用 Lombok 的
@EqualsAndHashCode(onlyExplicitlyIncluded = true)显式指定字段，避免漏掉新增字段导致判重失效 - 测试时加一条断言：
assert obj.hashCode() == obj.clone().hashCode();，验证不变性
规避迭代与修改并发导致的隐性开销
HashSet 迭代器是 fail-fast 的，但真正影响性能的不是异常本身，而是遍历时做 remove/add 引发的结构性修改，迫使后续操作重新定位。
- 需要边遍历边清理？改用
removeIf(predicate)，它内部一次性完成，比 for-each + iterator.remove() 快 20% 以上 - 高频读 + 偶尔写场景，考虑用
CopyOnWriteArraySet（小数据量）或ConcurrentSkipListSet（大数据+排序需求），但注意它们的写操作代价更高 - 纯判重用途（如幂等校验），用完即弃比长期持有更安全——避免因对象状态变化引发的逻辑漂移
慎用 null 和装箱类型
null 在 HashSet 中只允许一个，但它会固定落在哈希表索引 0 的位置；Integer、Long 等装箱类型存在缓存机制（-128~127），超出范围后每次 new 都是新对象，hashCode 虽一致但 equals 可能失败（若没重写）。
- 业务 ID 统一用 Long 类型而非 long，但确保所有地方都走 valueOf()，避免 new Long()
- 判重键尽量用原始语义明确的不可变对象（如 UUID、String、Long），少用复合对象
- 如果 key 是字符串且长度固定（如 32 位 MD5），可考虑用
String.hashCode()结果做二级缓存，跳过部分 equals 调用（需实测收益）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
