Java Stream distinct() 陷阱解析

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 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_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_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;
}

运行上述代码，输出结果可能如下：

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 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 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 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() 行为异常，无法正确去重。解决此问题的最佳实践是：

1. 避免在流操作中修改元素的状态，尤其是不应修改影响 equals() 和 hashCode() 的字段。
2. 优先使用不可变对象，例如 Java Record，它们从设计上就消除了此类问题。
3. 如果必须进行转换，请创建并返回新的对象实例，而不是修改现有实例。

遵循这些原则，可以确保 Java Stream 操作的正确性和健壮性，特别是在处理集合去重等场景时。