如何利用 Stream.distinct() 去除集合流中的重复元素

如何利用 Stream.distinct() 去除集合流中的重复元素

Stream.distinct() 依赖对象的 equals() 和 hashCode()

这里有个关键点需要先搞清楚：distinct() 并不是对对象进行深度的值比较。它的底层逻辑，其实是调用每个元素的 equals() 和 hashCode() 方法来判断是否重复。这意味着，如果你传入的是自定义对象（比如一个 User 类），但没有重写这两个方法，那么即使两个对象的字段内容完全一样，也会被当作不同的元素保留下来。

• 对于 String、Integer 这类 JDK 内置类型，它们已经默认实现了正确的逻辑，可以直接使用。
• 对于自定义类，就必须手动重写 equals() 和 hashCode()，而且两者的逻辑必须保持一致。
• 如果只重写了 equals() 却忘了 hashCode()，distinct() 的行为可能会失效，或者变得不稳定，这可是个经典的坑。

distinct() 是有状态操作，不能并行流里随意替换顺序

distinct() 在内部使用了一个 LinkedHashSet 来缓存已经遇到过的元素。这个机制带来了两个特点：一是它会保留第一次出现的元素，二是它会尽力维持原始的顺序。然而，一旦进入并行流的世界，情况就变了。所谓的“第一次出现”，完全取决于线程的调度顺序，最终结果的一致性也就无法保证了。

• 串行流：Stream.of("a", "b", "a").distinct().toList() 的结果总是确定的 ["a", "b"]。
• 并行流：Stream.of("a", "b", "a").parallel().distinct().toList() 的结果就不确定了，可能是 ["a", "b"]，也可能是 ["b", "a"]。
• 如果业务场景要求并行处理、去重并且还要保持稳定顺序，通常的解决方案是先调用 sorted() 排序，或者干脆不使用 distinct()，转而采用 Collectors.toCollection(LinkedHashSet::new) 这类收集器。

distinct() 不适用于按某个字段去重的场景

这是另一个常见的误解。假设你有一个 List，想根据 userId 字段来去重，distinct() 是做不到的——它只能判断整个对象是否相等，无法让你指定按哪个字段去重。

• 错误写法：users.stream().distinct()。这依赖的是整个 User 对象的 equals() 方法，往往不是业务真正需要的语义。
• 正确思路：通常需要借助 Collectors.toMap() 或 Collectors.collectingAndThen()，配合 TreeSet 或 LinkedHashMap 来实现。
• 常用替代方案：users.stream().collect(Collectors.toMap(User::getId, u -> u, (a, b) -> a)).values()。这个写法清晰表达了“以 id 为键，保留第一个遇到的元素”的意图。

性能和内存开销比想象中大

别小看 distinct() 的开销。因为它需要缓存所有已经遍历过的元素，在最坏的情况下（所有元素都不重复），其内存占用会与输入流的长度成正比。同时，每次遇到新元素都要去哈希表里查询一次，也有计算成本。

• 面对大数据量（比如百万级别）时，这个缓存集合很容易引发内存溢出（OOM），或者显著拖慢整个处理流程的速度。
• 如果去重只是为了统计数量，使用 stream.distinct().count() 不如 stream.collect(Collectors.toSet()).size() 来得清晰，而且后者对中间集合的生命周期有更明确的控制。
• 如果上游数据已经是排序好的，其实可以手动编写逻辑来跳过相邻的重复项（类似于归并排序中的去重思路），从而完全避免额外的集合开销。

话说回来，在实际使用中，不能只满足于“代码能跑通”。重点要审视几个方面：对象是如何定义的、数据规模有多大、是否需要保留顺序、业务上是否真的需要整个对象级别的判重。这几个问题如果没理清楚，distinct() 很容易就会变成一个隐蔽的问题来源。