如何在 Java 中利用 Stream.distinct() 配合自定义 equals 实现对象流的去重-java教程-PHP中文网

distinct()对自定义对象默认不生效，因其依赖equals()和hashcode()判断重复；未重写时使用object默认实现（基于内存地址），导致字段相同但实例不同的对象无法去重。

如何在 java 中利用 stream.distinct() 配合自定义 equals 实现对象流的去重

distinct() 为什么对自定义对象默认不生效

Stream.distinct() 底层依赖对象的 equals() 和 hashCode() 判断是否重复。如果你没重写这两个方法，它用的是 Object 的默认实现——也就是基于内存地址比较。哪怕两个对象字段值一模一样，只要不是同一个实例，distinct() 就认为它们不同。

常见错误现象：stream.distinct() 调用后集合长度没变，日志里看到一堆“相同”对象还在。

必须同时满足两个条件才有效：

在目标类中重写 equals(Object) 和 hashCode()
equals() 的逻辑要和你期望的“去重维度”一致（比如只比 id，或比 name + email）

如何安全地重写 equals 和 hashCode

别手写。IDE 自动生成最稳妥，避免漏掉字段、null 判断或对称性问题。以 IntelliJ 为例：右键 → Generate → equals() and hashCode()，勾选你真正用于判重的字段（比如 userId 和 tenantId），不要全选。

关键细节：

如果用 Lombok，加 @EqualsAndHashCode(onlyExplicitlyIncluded = true) + 在字段上加 @EqualsAndHashCode.Include，否则它会把所有非静态非瞬态字段都纳入，容易误伤
字段含 Collection 或嵌套对象时，确保其自身也正确定义了 equals()，否则外层判等会失败
hashCode() 必须与 equals() 保持契约：相等的对象必须有相同哈希值；哈希值相同不要求一定相等

distinct() 的替代方案：当不能改实体类时

如果实体是第三方库的类、或你无权修改源码（比如 org.springframework.http.HttpHeaders），就不能靠重写 equals()。这时得绕过 distinct()，用 collect() + Collectors.toMap() 或 Collectors.toCollection() 手动控制去重逻辑。

Gradle 9.8.0

下载

例如按 id 去重（保留第一个）：

list.stream()
    .collect(Collectors.toMap(
        User::getId, 
        user -> user, 
        (u1, u2) -> u1 // 保留第一个
    ))
    .values();

注意点：

这个操作返回的是 Collection<user></user>，不是 List，顺序不保证（除非用 LinkedHashMap::new 作 supplier）
如果去重键可能为 null，toMap() 会抛 NullPointerException，需提前过滤或用 Collectors.collectingAndThen() 包装
性能上，distinct() 是短路操作，而 toMap() 是全量收集，大数据量时内存占用略高

distinct() 的实际使用陷阱

最容易被忽略的一点：distinct() 是无状态中间操作，但它依赖的 equals() 如果访问了外部可变状态（比如某个静态计数器、或当前时间戳），结果就不可预测，甚至线程不安全。

另一个典型坑：

在 parallelStream() 中用 distinct()，底层用的是 ConcurrentHashMap，但前提是你的 hashCode() 分布足够均匀，否则会出现哈希冲突导致去重失效或性能骤降
如果实体字段是 BigDecimal 或 Double，直接用 equals() 比较可能因精度问题失败，建议统一转成 String 或用 compareTo() == 0
Stream 流水线一旦结束（比如调用了 forEach 或 collect），就不能再复用；反复调用 distinct() 要重新生成 stream