Java Stream API规约操作复杂计算优化方案咨询

你不需要额外单独遍历计算总支出，可以通过自定义收集器，在第一次遍历消费支出记录时同时维护两个计算状态，最终实现和手写for循环完全一致的两次遍历逻辑，没有额外性能损耗。
核心思路是在流收集阶段同时完成两个计算目标：

• 按用户维度累计个人总支出
• 累计全局所有支出的总和
  第一次遍历结束后计算人均分摊额度，再做一次用户维度的差值计算即可得到最终结果，全程没有冗余遍历。
  实现代码如下：

@Override
public Map<User, BigDecimal> getCurrentBalance(Group group) {
    final BigDecimal defaultTotalWeight = BigDecimal.valueOf(group.getDefaultTotalWeight());

    // Java 16+可直接用record作为累加容器，低版本可替换为自定义静态内部类
    record Accumulator(Map<User, BigDecimal> userExpenseMap, BigDecimal totalExpense) {}

    Accumulator computeResult = group.getExpenses().stream()
            .collect(
                    // 初始状态：空的用户支出Map、总支出为0
                    () -> new Accumulator(new HashMap<>(), BigDecimal.ZERO),
                    // 元素累加逻辑：同步更新对应用户支出、全局总支出
                    (acc, expense) -> {
                        acc.userExpenseMap().merge(
                                expense.getUser(),
                                expense.getAmount(),
                                BigDecimal::add
                        );
                        // 使用可变累加类时可直接修改属性，无需新建实例
                        return new Accumulator(
                                acc.userExpenseMap(),
                                acc.totalExpense().add(expense.getAmount())
                        );
                    },
                    // 并行流场景下的分片结果合并逻辑
                    (acc1, acc2) -> {
                        acc2.userExpenseMap().forEach((user, amount) ->
                                acc1.userExpenseMap().merge(user, amount, BigDecimal::add)
                        );
                        return new Accumulator(
                                acc1.userExpenseMap(),
                                acc1.totalExpense().add(acc2.totalExpense())
                        );
                    }
            );

    BigDecimal averageExpensePerUser = computeResult.totalExpense().divide(defaultTotalWeight);
    // 第二次遍历：计算每个用户的实际余额
    return computeResult.userExpenseMap().entrySet().stream()
            .collect(Collectors.toUnmodifiableMap(
                    Map.Entry::getKey,
                    entry -> entry.getValue().subtract(averageExpensePerUser)
            ));
}

如果使用Java 16以下版本，将record替换为如下可变累加类即可，性能会比不可变record稍好：

private static class BalanceAccumulator {
    Map<User, BigDecimal> userExpenses = new HashMap<>();
    BigDecimal totalExpense = BigDecimal.ZERO;
}

这类场景没有绝对的正确答案，根据团队技术栈和代码规范选择即可：

• 上述Stream实现逻辑清晰，遍历次数和手写for循环完全一致，没有冗余开销，在熟悉Stream API的团队中是完全可落地的方案，同时天然支持并行流适配（只要Expense、User类实现了必要的equals/hashCode逻辑）
• 你写的普通for循环版本可读性更强，没有Stream的抽象层开销，断点调试更方便，对于不熟悉Stream自定义收集器的开发者更友好，也是非常好的实现
• 你最初的Stream实现存在两个小问题：一是总共做了3次遍历，比必要的遍历次数多一次；二是在forEach中直接修改Map的value属于副作用操作，不符合Stream API的无副作用设计规范，并行场景下可能出现不可预期的问题。

内容的提问来源于stack exchange，提问作者Jakub Znamenáček