HashSet判重效率高但受使用方式影响，关键在减少哈希冲突、优化equals尽早返回、合理设置初始容量与负载因子，并避免频繁创建实例。
HashSet 判重本身已是 Java 中效率最高的标准方案之一，平均时间复杂度稳定在 O(1)。但实际性能会受实现细节影响，真正拖慢判重的往往不是 HashSet 本身，而是使用方式和对象特性。提升关键在三点：减少哈希冲突、避免无效 equals 调用、控制扩容开销。
确保 hashCode 分布均匀
哈希值越分散，元素在底层 HashMap 的桶中分布越均匀，冲突就越少。冲突一多，就得退化成链表或红黑树遍历，判重就从 O(1) 变成 O(n)。
- 自定义类必须用 Objects.hash(...) 或合理组合字段生成 hashCode，避免只依赖单一字段（比如只用 id）
- 避免 hashCode 返回常量（如始终 return 1），这会让所有元素挤进同一个桶
- 对字符串、数字等 JDK 内置类型无需额外处理，它们的 hashCode 实现已高度优化
让 equals 尽早返回 false
只有哈希值相等时才会触发 equals 比较。但一旦进入 equals，方法内部逻辑越重，开销越大。尤其当字段含长字符串、嵌套对象或需计算时，性能明显下降。
- 在 equals 中优先比较轻量字段（如 int、boolean），再比字符串或集合
- 用 == 快速判断引用相同（this == obj），再 instanceof 判断类型，最后才展开字段比对
- 避免在 equals 中调用耗时操作，比如数据库查询、IO、正则匹配
合理设置初始容量与负载因子
HashSet 默认初始容量是 16，负载因子 0.75。如果预估要存 10 万条数据，不设初始容量会导致多次扩容——每次扩容都要 rehash 全部已有元素，极大拖慢批量 add 过程。
立即学习“Java免费学习笔记（深入）”；
- 构造时显式指定容量：new HashSet(expectedSize / 0.75 + 1)
- 若确定数据量且追求极致性能，可略调高负载因子（如 0.85），但会轻微增加冲突概率
- 注意：容量必须是 2 的幂，JDK 会自动向上取最近的 2 的幂
避免在循环中反复创建 HashSet
高频调用场景（如日志过滤、实时风控）若每次 new HashSet()，对象创建+初始化开销叠加 GC 压力，反而抵消了判重优势。
- 复用线程安全的静态实例（如 Collections.synchronizedSet(new HashSet())），或使用 ThreadLocal
- 对单次任务，用完即弃没问题；对长期运行服务，考虑池化或复用
- 注意：HashSet 非线程安全，多线程共享必须加锁或用 CopyOnWriteArraySet（仅适合读多写少）
