Java Set接口核心特点及去重原理解析

Set能自动去重是因为HashSet等实现类基于hashCode()和equals()判断重复：只有二者均相同才视为重复；自定义类必须同时重写且逻辑一致，否则去重失效。

Set为什么能自动去重？关键在 hashCode() 和 equals()

Set 接口本身不负责去重逻辑，真正起作用的是它的实现类（如 HashSet）——而它们的去重机制完全依赖两个方法：hashCode() 和 equals()。 当你调用 add(e) 时，HashSet 实际上是把元素 e 当作 HashMap 的 key 存进去：

return map.put(e, PRESENT) == null;

• 如果只重写 equals() 不重写 hashCode() → 哈希桶位置分散，重复对象可能被放进不同桶，contains() 或 add() 判定失效
• 如果只重写 hashCode() 不重写 equals() → 所有对象哈希值相同，全挤进同一个链表/红黑树，性能退化为 O(n)，且仍无法准确判等
• 自定义类（如 Student）必须同时重写二者，且逻辑保持一致：相等的对象必须返回相同 hashCode()

HashSet 插入顺序和遍历顺序为啥不一致？

HashSet 是无序的，这不是“随机”，而是由底层哈希表结构决定的：元素根据 hashCode() 落入数组索引，再经链表或红黑树组织。JDK 8 后即使扩容重哈希，顺序也不保证与插入一致。

• 想按插入顺序遍历？换用 LinkedHashSet —— 它在 HashSet 基础上加了双向链表维护插入序列
• 想按大小/字典序遍历？用 TreeSet，但要求元素实现 Comparable 或传入 Comparator
• HashSet 允许一个 null 元素（因为 HashMap 支持 null key），但 TreeSet 不允许（比较时会抛 NullPointerException）

常见去重失败场景：不是 Set 不行，是你没配对重写方法

开发中最常踩的坑是：往 HashSet<Student> 里反复添加姓名年龄相同的 Student 对象，结果发现没去重。打印 size() 发现是 5 而不是 1 —— 这几乎 100% 是因为 Student 没重写 hashCode() 和 equals()。

• IDE 自动生成即可（IntelliJ 快捷键 Alt+Insert → “Generate…” → 选 equals() and hashCode()）
• 不要手写 hashCode() 返回固定值（如 return 1;），这会让所有对象落在同一桶，退化成链表查找
• 字段选错也会出问题：比如只用 name 生成 hashCode()，但 equals() 比较了 name + age → 违反契约，行为不可预测

性能差异大不大？选错实现类真会影响线上表现

三种主流 Set 实现的增删查时间复杂度差别明显：

• HashSet：平均 O(1)，适合高频增删查、不关心顺序的场景（如缓存去重、日志过滤）
• LinkedHashSet：O(1)，额外占用链表内存，仅多一点点开销，但换来可预测的遍历顺序
• TreeSet：O(log n)，每次操作都要走红黑树平衡，数据量大时（>10⁴）延迟可感知；但它支持 first()、last()、headSet() 等范围操作，这是另两类做不到的

别为了“看起来高级”用 TreeSet 做简单去重——除非你明确需要排序或区间查询。大多数日志去重、ID 去重、参数校验场景，HashSet 就是最优解。