Java使用Set去重元素全解析

Java中使用Set去重看似简单，实则暗藏陷阱：HashSet去重失败往往源于未正确重写equals()和hashCode()，导致逻辑相同的对象因内存地址不同而被重复保留；LinkedHashSet是兼顾去重与插入顺序的高效选择，但需注意构造方式以避免顺序错乱；Stream的distinct()虽简洁，却无法按指定字段灵活去重，复杂场景需结合filter或toMap定制逻辑；而真正关键的决策在于——只要SQL层能完成（如DISTINCT、GROUP BY或窗口函数），就绝不在Java层兜底去重，否则不仅浪费资源，还可能掩盖数据一致性隐患。

为什么直接用 HashSet 有时去重失败？

根本原因不是 HashSet 不行，而是你存的对象没正确重写 equals() 和 hashCode()。比如用自定义类 User 存进 HashSet，但没重写这两个方法，那两个字段完全相同的 User 实例仍会被视为不同元素——因为默认比较的是内存地址。

• 只重写 equals() 不重写 hashCode()：违反哈希契约，可能导致元素“消失”（contains() 返回 false，但实际存在）
• 字段参与比较的，必须全部出现在 hashCode() 计算中（推荐用 Objects.hash(...)）
• 使用 Lombok 的话，加 @EqualsAndHashCode 注解最省事，但要确认 exclude 或 of 指定的字段符合业务去重逻辑

如何对 List 快速去重并保持插入顺序？

用 LinkedHashSet 是最直接的方式：它既具备 HashSet 的去重能力，又通过链表维护插入顺序。

List<String> original = Arrays.asList("a", "b", "a", "c");
List<String> unique = new ArrayList<>(new LinkedHashSet<>(original));

• 注意：构造 LinkedHashSet 时传入原 List，会按遍历顺序去重；不能反过来先建空集再 addAll()，否则顺序可能错乱
• 如果原 List 很大（比如百万级），这种写法会额外分配一次内存；可考虑用 Stream + Collectors.toCollection(LinkedHashSet::new) 避免中间 List
• TreeSet 虽然也能去重，但会按自然序或自定义序排序，不保证原始顺序

Stream API 去重时 distinct() 的限制在哪？

distinct() 内部依赖元素的 equals()/hashCode()，和 HashSet 行为一致——所以同样要求对象正确实现这两个方法。它不支持按指定字段去重（比如只看 id 字段）。

• 想按单个字段去重？得自己写 filter() + 状态容器，例如：

  Set<Long> seenIds = ConcurrentHashMap.newKeySet();
  list.stream()
      .filter(item -> seenIds.add(item.getId()))
      .collect(Collectors.toList());

• 用 Collectors.toMap() 可实现更灵活的去重逻辑（如保留最新/最早元素），但要注意键冲突时的合并函数
• distinct() 是有状态操作，不能并行流里随意用——虽然它内部做了线程安全处理，但并行下顺序不保证，且性能未必优于单线程

数据库查出来的 List 去重，该在 Java 层还是 SQL 层做？

优先在 SQL 层用 DISTINCT 或 GROUP BY。Java 层去重是兜底手段，不是首选。

• SQL 去重能减少网络传输量、降低 JVM 堆压力，尤其当结果集含大量重复且字段多时
• 如果去重要求复杂（比如“相同 name 下取 created_time 最大的那条”），SQL 用 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) 更可靠
• Java 层去重容易掩盖数据一致性问题：比如同名用户本应有唯一 ID，但 DB 里因 bug 出现了两条，Java 层一去重反而让问题更难被发现

真正需要 Java 层去重的场景，往往是多个异构数据源合并后统一清洗，或者业务规则无法用 SQL 表达（比如基于外部服务返回值判断是否重复）。

今天关于《Java使用Set去重元素全解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！