登录
首页 >  文章 >  java教程

Java Stream 去重技巧:使用 distinct() 与 equals 方法

时间:2026-05-25 19:45:31 157浏览 收藏

Java Stream 的 distinct() 方法看似简单,实则暗藏玄机:自定义对象去重失败往往源于未正确重写 equals() 和 hashCode()——二者必须成对出现、逻辑一致,否则底层 LinkedHashSet 无法准确识别“相等”;而 String 等包装类可直接使用,得益于 JDK 已实现的值语义;若需按单字段(如 id)去重,则应避开污染类语义的 equals 改写,转而采用 toMap() 实现安全、清晰的投影去重;此外,parallelStream().distinct() 虽线程安全,却会丢失原始顺序,适用场景需谨慎权衡——掌握这些关键细节,才能让去重真正可靠、高效、无副作用。

怎么利用 Stream.distinct() 基于 equals 方法对流数据进行去重

Stream.distinct() 为什么没去重?先看 equals 和 hashCode 是否配套

直接调用 Stream.distinct() 却发现重复对象没被去掉,大概率是自定义类没重写 equals()hashCode(),或者只重写了其中一个。Java 的 distinct() 内部用的是 LinkedHashSet,它依赖 hashCode() 快速分桶、再用 equals() 精确比对。两者不一致会导致“看起来相等但被当成不同对象”。

实操建议:

  • 必须同时重写 equals(Object)hashCode(),且逻辑自洽(比如都基于 idname 字段)
  • 用 IDE 自动生成(如 IntelliJ 的 Alt+Insert → equals and hashCode),别手写漏字段
  • 如果字段含 null,确保 equals() 中用 Objects.equals(a, b) 而非 a.equals(b)

String、Integer 等包装类能直接用 distinct() 吗?

可以,而且开箱即用。因为 StringIntegerLong 等 JDK 自带类型,其 equals()hashCode() 已正确定义(值语义)。例如:

List<String> list = Arrays.asList("a", "b", "a", "c");
list.stream().distinct().collect(Collectors.toList()); // ["a", "b", "c"]

注意点:

  • new String("a")"a"equals() 下相等,所以会被去重
  • distinct() 不改变原始顺序,输出顺序和首次出现位置一致
  • 如果数据量极大(千万级),distinct() 的内存占用≈去重后集合大小,需留意堆内存

想按某个字段去重(比如只看 id),还能用 distinct() 吗?

不能直接用——distinct() 只认整个对象的 equals(),不支持“按字段投影去重”。强行改 equals() 只比 id,会污染该类在其他场景下的语义(比如本该按全部字段判断相等的地方出错)。

正确做法是用 Collectors.toMap()Collectors.collectingAndThen() 模拟“按 key 去重”:

Map<Long, User> map = users.stream()
    .collect(Collectors.toMap(
        User::getId,     // key: id
        user -> user,    // value: 整个对象
        (u1, u2) -> u1  // 冲突时保留第一个
    ));
List<User> distinctByid = new ArrayList<>(map.values());

关键细节:

  • toMap 的 merge 函数决定保留哪个:用 (u1, u2) -> u1 保首个,(u1, u2) -> u2 保末个
  • 如果 getId() 可能为 null,需先过滤或改用 Collectors.groupingBy() + map.values().stream().map(list -> list.get(0))
  • 这种写法比 distinct() 多一次哈希表构建,但语义清晰、无副作用

parallelStream().distinct() 线程安全吗?结果顺序还保证吗?

线程安全,但不保证顺序。JDK 文档明确说明:distinct() 在并行流中仍能正确去重(底层用线程安全的 ConcurrentHashMap 替代 LinkedHashSet),但输出顺序是任意的——因为多个线程并发收集,无法维持原始 encounter order。

所以:

  • 若你依赖顺序(比如“取每个重复组的第一个”),别用 parallelStream().distinct()
  • 若只是统计去重后数量,或后续还要排序,那并行版能提速
  • 没有银弹:并行带来的开销(拆分/合并/同步)在小数据集(
实际用的时候,最容易被忽略的是自定义类的 hashCode() 实现是否真和 equals() 对齐——哪怕只漏一个字段,或者用了可变字段(比如把 lastModifiedTime 放进 hashCode),都会让 distinct() 行为不可预测。

文中关于的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《Java Stream 去重技巧:使用 distinct() 与 equals 方法》文章吧,也可关注golang学习网公众号了解相关技术文章。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>