Java Stream分组后保留每组首条记录的收集器写法

Java Stream 分组后要保留每组首条记录，关键不是把 `groupingBy` 换成另一段链式调用，而是先定义“首条”的排序契约。输入已经按“组内优先级升序、id 升序”稳定排序时，常规场景用 `toMap` 的合并函数保留旧值即可；规则更复杂，再把比较逻辑收进自定义 `Collector`。

分组结果不稳定，根因通常在“首条”没有定义

常见故障是订单、设备或用户数据按业务键分组后，结果数量看起来正确，但留下的那一条并不是优先级最高的记录。groupingBy 默认收集的是每组列表，它不会替业务决定列表中的哪一条算“首条”；如果后面直接取 list.get(0)，就把偶然的输入顺序当成了规则。

复盘这类问题可以按三段看：先确认组键是否正确，再确认组内排序是否稳定，最后才选择收集器。推荐使用“优先级升序、创建时间升序、id 升序”的组合排序，最后一个字段负责打破完全相同的业务条件。

先把排序契约写进输入关系

下面的示例把每个用户的首个有效地址定义为：优先级更小者优先；优先级相同则创建时间更早者优先；仍相同则 id 更小者优先。这里的代码是文章示例，不代表已在本机运行。

// 先建立稳定的组内排序，后面的“保留旧值”才有业务含义
Comparator
 firstAddress = Comparator
    .comparingInt(Address::priority)
    .thenComparing(Address::createdAt)
    .thenComparingLong(Address::id);

List
 ordered = addresses.stream()
    // 过滤无效记录，避免首条被空值占据
    .filter(Address::enabled)
    // 排序字段必须覆盖相同业务条件下的平局情况
    .sorted(firstAddress)
    .toList();

简单保留规则用 toMap 合并旧值

输入已经满足稳定排序后，可以让 map 的 key 作为分组键，value 作为当前记录。重复 key 出现时，合并函数返回左侧旧值，最终每个用户只留下排在最前的地址。

// key 是分组字段；重复 key 时返回旧值，保留排序后的首条
Map firstByUser = ordered.stream()
    .collect(Collectors.toMap(
        Address::userId,
        Function.identity(),
        (oldValue, newValue) -> oldValue,
        LinkedHashMap::new // 保留首次插入的组顺序，便于输出和排查
    ));

这里的 oldValue 只有在输入顺序已被契约约束时才等于业务上的首条。若直接对原始集合调用 toMap，代码虽然能编译，保留的可能只是集合当前排列中的第一条。

比较逻辑复杂时，把规则集中到自定义 Collector

如果规则变成“启用记录优先、再比较优先级、缺失时间视为最晚、同时统计每组淘汰数量”，把条件拆散在多个 filter 和 merge 中会越来越难读。这时可以让累加器只保留候选对象，并让比较器成为唯一决策点。

// 每组只保留更优候选；比较器集中表达全部业务优先级
Collector
> firstCollector =
    Collectors.toMap(
        Address::userId,
        Function.identity(),
        (left, right) -> firstAddress.compare(left, right)  result = addresses.stream()
    // 复杂比较放在 collector 的合并点，调用方保持简洁
    .collect(firstCollector);

上线前的四项边界检查

常见问题

为什么不直接使用 groupingBy 后取第一条？

可以使用，但必须先对每组建立稳定排序，而且会暂存完整列表。只需一条记录时，toMap 更直接，也减少了中间集合。

并行流能保证保留排序后的首条吗？

不能把它当作默认保证。并行合并会改变局部结果的组合顺序；若首条是业务结果而不是性能细节，优先使用顺序流，或让合并函数按完整比较器选出更优对象。

什么时候必须写自定义 Collector？

当每组需要同时保留候选、计数、淘汰原因或多个派生字段时再写。若只是按固定排序每组保留一条，带 merge 的 toMap 已足够清楚。