Java8基于公共属性匹配不同类型列表赋值的Stream实现方案

你写的代码存在3个核心逻辑错误：

• filter中allMatch用法完全错误：allMatch要求流中所有元素都满足断言条件，相当于要求所有WorkflowStatus的userId都和当前User的userId相等，永远不可能匹配到正确结果；且lambda表达式中没有声明workflowStatus变量，语法本身就不成立。
• map操作逻辑错误：user.setWorkflowStatusId()是void返回类型，没有返回值，无法作为map的返回结果生成新的流元素。
• 双层流嵌套遍历的时间复杂度为O(n*m)，数据量稍大时性能很差。

核心思路是提前对WorkflowStatus列表按关联键userId构建索引Map，把单条匹配的时间复杂度从O(m)降到O(1)，整体时间复杂度为O(n+m)，是Java8处理多列表关联的标准写法。

// 第一步：预构建userId到WorkflowStatus的映射索引，处理重复键时按需选择保留已有值/新值
Map<Long, WorkflowStatus> userStatusMap = workflowStatuses.stream()
        .collect(Collectors.toMap(
                WorkflowStatus::getUserId,
                status -> status,
                (oldVal, newVal) -> oldVal
        ));

// 第二步：遍历User列表，从索引中直接取匹配的状态值赋值
List<User> result = users.stream()
        .peek(user -> {
            WorkflowStatus matched = userStatusMap.get(user.getUserId());
            if (matched != null) {
                user.setWorkflowStatusId(matched.getWorkflowStatusId());
            }
        })
        .collect(Collectors.toList());

说明：peek方法专门用于流元素的侧效操作（比如修改属性、打印日志），适合当前不需要替换User对象、仅修改属性的场景。如果你的编码规范禁止修改入参对象，可以把peek换成map，在map中新建User对象拷贝所有属性后赋值workflowStatusId返回即可。

如果不考虑性能，仅修正你原有写法的逻辑错误，可以用findFirst+ifPresent实现匹配赋值，但是不推荐在生产环境大数据量场景使用：

List<User> result = users.stream()
        .peek(user -> workflowStatuses.stream()
                .filter(status -> user.getUserId().equals(status.getUserId()))
                .findFirst()
                .ifPresent(status -> user.setWorkflowStatusId(status.getWorkflowStatusId()))
        )
        .collect(Collectors.toList());

• 优先构建关联键索引：被关联的列表如果需要反复匹配，一律提前转成以关联键为key的Map，避免嵌套遍历。
• 明确关联基数：如果是一对一关联用Collectors.toMap，注意写重复键合并函数避免抛异常；如果是一对多关联用Collectors.groupingBy生成Map<关联键, List<关联对象>>结构。
• 高开销操作前置：数据库查询、远程调用、大列表遍历这类高开销操作不要写在流的中间操作（filter/map/peek）里，要提前在流操作外完成预处理。

内容的提问来源于stack exchange，提问作者Mohsin M