Javadistinct去重方法详解

Java中`Stream.distinct()`看似简单，实则暗藏关键陷阱：它完全依赖`equals()`和`hashCode()`的正确实现，自定义类若未重写二者，字段相同的对象仍会被视为不同元素；按单个字段（如name）去重需借助`filter`配合`ConcurrentHashMap.newKeySet()`确保线程安全与语义准确；而`TreeSet`收集则适合需排序+去重的场景，但会牺牲原始顺序；更重要的是，所有技术选择都必须严格对齐业务定义的“重复”标准——是手机号、用户名还是组合字段？脱离业务语义的去重代码，再优雅也终将埋下隐患。

Java 8 Stream.distinct() 的适用前提和限制

distinct() 方法本身不依赖元素的业务逻辑，但它**严格依赖 equals() 和 hashCode() 的正确实现**。如果自定义对象没重写这两个方法，哪怕两个对象字段完全相同，distinct() 也会把它们视为不同元素。

常见错误现象：Stream.of(new User("Alice", 25), new User("Alice", 25)).distinct().count() 返回 2 —— 因为默认使用 Object 的 hashCode()，地址不同即不同。

• 对 String、Integer 等 JDK 内置类型可直接用 distinct()
• 对自定义类，必须确保 equals()/hashCode() 覆盖了所有参与“相等判断”的字段
• 注意：distinct() 是有状态操作，不能并行流中随意替换为无状态替代方案

按对象某个字段去重（比如 name 去重保留第一个）

标准 distinct() 不支持“按字段去重”，它只认整个对象是否重复。要实现“按 name 去重”，本质是需要一个“已见 name 集合”做状态记录。

推荐写法（线程安全、语义清晰）：

Set<String> seen = ConcurrentHashMap.newKeySet();
list.stream()
    .filter(user -> seen.add(user.getName()))
    .collect(Collectors.toList());

• 用 ConcurrentHashMap.newKeySet() 而非 HashSet，避免并行流下 add() 竞态
• seen.add(x) 返回 true 表示首次加入，正好作为 filter 条件
• 不建议用 Collectors.toMap() + Function.identity()，容易因重复 key 抛 IllegalStateException

distinct() 在 List、Set、Map 转换中的性能差异

distinct() 本身内部用的是 LinkedHashSet 缓存已见元素，所以时间复杂度是 O(n)，但会额外占用 O(n) 空间。实际效果受上游数据结构影响很大：

• 从 ArrayList 流式去重：典型场景，无额外开销
• 从已有 HashSet 开始流：此时再调 distinct() 完全冗余，纯属浪费 CPU 和内存
• 从数据库查出的 List>：每个 Map 默认无合理 equals()，distinct() 几乎无效，应先转成确定类型的对象再处理

替代方案：用 TreeSet 自定义去重逻辑（适合排序+去重）

如果既要按某字段去重，又希望结果有序（比如按 id 升序），TreeSet 比 “filter + Set 记录” 更简洁：

Set<User> unique = list.stream()
    .collect(Collectors.toCollection(
        () -> new TreeSet<>(Comparator.comparing(User::getName))
    ));

• 注意：这会丢弃原始顺序；若需保持首次出现顺序，不能用此法
• TreeSet 构造时传入的 Comparator 决定“重复”的含义 —— 两个元素比较结果为 0 即视为重复
• 该方式在元素量大且已知需排序时，比先 distinct() 再 sorted() 略高效（一次遍历完成两件事）

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Javadistinct去重方法详解》文章吧，也可关注golang学习网公众号了解相关技术文章。