本文深入探讨了Java Stream distinct() 操作的工作原理，特别是当处理可变对象时可能遇到的意外行为。distinct() 依赖于对象的 equals() 和 hashCode() 方法来识别重复元素。文章通过具体代码示例，揭示了在流处理过程中修改对象的关键字段（这些字段影响 equals() 和 hashCode() 的计算）如何导致 distinct() 失效。最后，提供了避免此类问题的策略，包括使用不可变对象（如Java Record）和遵循函数式编程范式，以确保流操作的正确性。
Java Stream distinct() 的工作原理
Java Stream API 中的 distinct() 操作用于返回由流中不同元素组成的流。它的核心机制是依赖于元素的 equals() 和 hashCode() 方法来判断两个对象是否相等。当 distinct() 处理流中的元素时，它会维护一个内部的集合（通常是 HashSet 的变体）来存储已经遇到的元素。每当遇到一个新元素时，它会尝试将其添加到这个内部集合中。如果 add() 方法返回 true（表示元素是新的），则该元素会被传递到下游；如果返回 false（表示元素已存在），则该元素会被过滤掉。
可变对象与 distinct() 的冲突
在处理不可变对象（如 String、Integer 等）时，distinct() 通常能按预期工作，因为它们的值一旦创建就不会改变，其 equals() 和 hashCode() 始终保持一致。然而，当流中包含可变对象，并且这些对象在流处理过程中被修改，特别是修改了影响 equals() 或 hashCode() 计算的字段时，distinct() 可能会产生出乎意料的结果。
考虑以下示例代码：
import lombok.AllArgsConstructor; import lombok.Data; import lombok.EqualsAndHashCode; import java.util.Arrays; import java.util.List; import java.util.stream.Collectors; public class StreamDistinctIssue { public static void main(String[] args) { // 示例1: 使用可变对象 TestBean List<TestBean> obj_list = Arrays.asList(new TestBean("aa"), new TestBean("bb"), new TestBean("bb")).stream() .distinct() // 期望去重 .map(tt -> { tt.col = tt.col + "_t"; // 修改了影响 equals/hashCode 的字段 return tt; }).collect(Collectors.toList()); System.out.println("TestBean 结果: " + obj_list); // 示例2: 使用不可变对象 String List<String> string_obj_list = Arrays.asList(new String("1"), new String("2"), new String("2")).stream() .distinct() .map(t -> t + "_t") .collect(Collectors.toList()); System.out.println("String (New Object) 结果: " + string_obj_list); // 示例3: 使用不可变对象 String (字面量) List<String> string_list = Arrays.asList("1", "2", "2").stream() .distinct() .map(t -> t + "_t") .collect(Collectors.toList()); System.out.println("String (Literal) 结果: " + string_list); } } @Data @AllArgsConstructor @EqualsAndHashCode class TestBean { String col; }
运行上述代码，输出结果可能如下：
立即学习“Java免费学习笔记（深入）”；
TestBean 结果: [TestBean(col=aa_t), TestBean(col=bb_t), TestBean(col=bb_t)] String (New Object) 结果: [1_t, 2_t] String (Literal) 结果: [1_t, 2_t]
可以看到，String 类型的流经过 distinct() 后成功去重，而 TestBean 类型的流却保留了重复的 bb 元素。
问题分析：
TestBean 类使用了 Lombok 的 @EqualsAndHashCode 注解，这意味着它的 equals() 和 hashCode() 方法是基于 col 字段生成的。当流执行到 .distinct() 操作时，它会根据当前元素的 col 值来判断是否重复。
问题出在 map 操作中：tt.col = tt.col + “_t”;。这个操作直接修改了 TestBean 实例的 col 字段。如果一个 TestBean(col=”bb”) 实例在 distinct() 内部的集合中被添加后，其 col 字段又被 map 操作修改为 bb_t，那么当流中出现另一个原始的 TestBean(col=”bb”) 实例时，distinct() 内部的集合可能无法正确识别它为重复元素。这是因为集合的查找（基于 hashCode() 和 equals()）依赖于元素在被添加时的状态。如果元素在集合中被修改了其哈希码或相等性状态，那么后续的查找将无法匹配到它，导致集合行为异常，从而使 distinct() 失效。
简而言之，当一个对象被放入哈希相关的集合（如 HashSet 或 HashMap）后，如果其 equals() 或 hashCode() 所依赖的字段被修改，那么该对象在集合中的行为将变得不可预测。distinct() 内部正是使用了类似的机制。
为了更直观地理解，考虑以下 HashSet 的简化示例：
import java.util.HashSet; import java.util.Set; public class HashSetMutationIssue { public static void main(String... args) { class MutableTestBean { String col; MutableTestBean(String col) { this.col = col; } @Override public int hashCode() { return col.hashCode(); // hashCode 依赖于 col } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; MutableTestBean that = (MutableTestBean) o; return col.equals(that.col); // equals 依赖于 col } @Override public String toString() { return "MutableTestBean(col='" + col + "')"; } } Set<MutableTestBean> set = new HashSet<>(); MutableTestBean x = new MutableTestBean("bb"); for (int i = 0; i < 5; i++) { System.out.println("set.add(x)=" + set.add(x)); // 尝试添加同一个对象 System.out.println("set.size()=" + set.size()); // 关键：修改了影响 hashCode 和 equals 的字段 x.col += "_t"; } } }
运行此代码，你会发现 set.size() 会逐渐增加，最终可能达到 5，而不是预期的 1。这是因为每次 x.col 被修改后，x 的 hashCode 和 equals 行为也随之改变，导致 HashSet 无法识别它与之前添加的“相同”对象。
避免 distinct() 陷阱的策略
为了确保 distinct() 操作的正确性，并遵循函数式编程中“无副作用”的原则，我们应采取以下策略：
1. 避免在流处理中修改对象状态
这是最根本的原则。Java Stream API 旨在支持函数式编程范式，其中操作通常不应产生副作用。这意味着不应该在 map、Filter 等中间操作中修改流中元素的状态，特别是那些影响 equals() 和 hashCode() 的字段。
如果确实需要对元素进行转换，应该返回一个新的对象实例，而不是修改原对象：
// 错误示范（修改原对象）： .map(tt -> { tt.col = tt.col + "_t"; return tt; }) // 正确示范（返回新对象）： .map(tt -> new TestBean(tt.col + "_t"))
2. 优先使用不可变对象
不可变对象是解决此类问题的最佳方案。一旦创建，其状态就不能改变，这意味着它们的 equals() 和 hashCode() 始终保持一致，从而保证了 distinct() 等集合操作的正确性。
Java 16 引入的 Record 类型是创建不可变数据类的理想选择。它们自动生成 equals()、hashCode()、toString() 和构造函数，且所有组件都是 final 的。
// 使用 Java Record 定义 TestBean record ImmutableTestBean(String col) {} public class StreamDistinctImmutable { public static void main(String[] args) { List<ImmutableTestBean> obj_list = Arrays.asList( new ImmutableTestBean("aa"), new ImmutableTestBean("bb"), new ImmutableTestBean("bb")) .stream() .distinct() // 此时 distinct 可以正常工作 .map(tt -> new ImmutableTestBean(tt.col() + "_t")) // 创建新对象 .collect(Collectors.toList()); System.out.println("ImmutableTestBean 结果: " + obj_list); // 预期输出: [ImmutableTestBean[col=aa_t], ImmutableTestBean[col=bb_t]] } }
3. 调整 distinct() 的位置（特定场景下）
如果你的业务逻辑确实需要在 map 操作中修改对象，并且这些修改不会影响 equals() 和 hashCode() 的计算（例如，修改了一个不参与 equals/hashCode 的字段），那么可以将 distinct() 放在 map 操作之后。
// 假设 TestBean 的 equals/hashCode 仅基于 id 字段，而 map 操作修改的是 name 字段 // 这种情况下，先 map 后 distinct 可能是可行的 // 但这不是解决上述问题的通用方案，因为上述问题中修改的正是影响 equals/hashCode 的字段 List<TestBean> obj_list = Arrays.asList(new TestBean("aa"), new TestBean("bb"), new TestBean("bb")).stream() .map(tt -> { tt.col = tt.col + "_t"; // 修改了字段 return tt; }) .distinct() // distinct 放在 map 之后 .collect(Collectors.toList()); // 在本例中，这仍然无法解决问题，因为 col 参与了 equals/hashCode
注意： 对于本文中 TestBean 的具体问题，这种方法是无效的，因为 map 操作修改的 col 字段正是 equals() 和 hashCode() 所依赖的。此策略仅适用于 map 操作修改的字段与 equals() 和 hashCode() 无关的情况。
注意事项
- 副作用：在 Java Stream API 中，应尽量避免在中间操作中产生副作用。这不仅是为了 distinct() 的正确性，也是为了提高代码的可读性、可维护性和并行处理的安全性。
- 哈希契约：记住 Java 中 equals() 和 hashCode() 的约定：如果两个对象 equals() 返回 true，那么它们的 hashCode() 必须相等。反之则不然。当一个对象被放入哈希集合后，如果其 hashCode() 发生改变，将破坏哈希表的内部结构，导致查找失败。
总结
Java Stream distinct() 操作的正确性高度依赖于流中元素的 equals() 和 hashCode() 方法。当处理可变对象时，如果在流的中间操作中修改了影响这些方法的字段，就可能导致 distinct() 行为异常，无法正确去重。解决此问题的最佳实践是：
- 避免在流操作中修改元素的状态，尤其是不应修改影响 equals() 和 hashCode() 的字段。
- 优先使用不可变对象，例如 Java Record，它们从设计上就消除了此类问题。
- 如果必须进行转换，请创建并返回新的对象实例，而不是修改现有实例。
遵循这些原则，可以确保 Java Stream 操作的正确性和健壮性，特别是在处理集合去重等场景时。
