Java Stream 的 toMap 遇到重复 key 怎么写：合并策略和分组边界

日常写Java Stream调用toMap做集合归集时，很容易碰到重复key直接抛运行时异常的问题，拿最常见的供应商商品同步场景举例，同一个sku出现两次并不罕见：一次来自早到的价目表，一次来自补充文件。把它们直接收进Collectors.toMap，只要映射后的key相同，双参数重载就会在收集时抛出IllegalStateException。修复不该是随手“覆盖一下”，而是先决定重复记录到底代表更新、冲突，还是需要完整保留的多条事实。

遇到toMap重复key不用乱加兜底逻辑，优先按业务语义选三类标准写法：能确定key天然唯一就保留原生异常及时抛错，要合并同key数据就自定义可读的merge函数，需要全量留存原始记录就直接走groupingBy分组，不要悄悄丢弃未做校验的原始数据。

先给出可落地的合并写法

下面的测试列表故意让BK-102出现两次。假设后一条是同一供应商稍后发来的修订价，业务约定以较新的revision为准。合并函数拿到的是同一个key对应的两个value；把规则直接写在收集位置，后续读代码的人能直接看到冲突的处理逻辑。

import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

record PriceRow(String sku, int price, int revision) {}

List rows = List.of(
    new PriceRow("BK-102", 58, 1),
    new PriceRow("BK-102", 62, 2),
    new PriceRow("PN-310", 19, 1)
);

Map latestBySku = rows.stream()
    .collect(Collectors.toMap(
        PriceRow::sku,
        row -> row,
        (left, right) -> left.revision() > right.revision() ? left : right
    ));

int selectedPrice = latestBySku.get("BK-102").price(); // 62

如果业务规则约定“第一条记录可信，后续出现的重复项直接忽略”，第三个参数可以写成(left, right) -> left；如果明确以最后进入流的值为准，则写成(left, right) -> right。这两种写法都不能直接套到所有场景：流的遍历顺序、数据源排序和重放机制都会直接影响“第一条”“最后一条”的实际指向。

规模变化后，先问重复值还能不能被压成一条

初始同步只有一份价目表时，直接归集的单值MapMap完全能满足查价需求。接入第二个供应商后，同key重复不再单纯是更新，也可能对应多个不同报价、不同仓库库存或者不同生效区间的记录。这时用合并函数强行选其中一条，只会把后续审计需要用到的信息提前抹除。

需要保留同一个key的全部原始记录时，最小的替换逻辑是groupingBy。它会先按指定维度完成聚合，后续的过滤规则可以在完整的记录列表上实现。这样“选最低价”“只保留已生效版本”或者“把冲突数据送人工核对”都能拿到足够的原始数据支撑。

Map> rowsBySku = rows.stream()
    .collect(Collectors.groupingBy(PriceRow::sku));

List duplicated = rowsBySku.get("BK-102");
int duplicateCount = duplicated.size(); // 2

选择逻辑很清晰：调用方只需要一个明确的单值结果，且冲突规则完全确定时，用toMap加自定义合并函数；调用方还要自行判断重复原因、展示多个候选项或者留存审计链路时，直接走groupingBy。不要为了让程序不报错，就直接把第二条数据悄无声息覆盖掉。

Map 类型和并行流是另一层取舍

带四个参数的toMap允许你自定义结果Map的生成工厂。比如接口需要稳定按插入顺序返回数据时，可以使用LinkedHashMap::new；需要按key自然排序返回结果时，再考虑TreeMap::new。自定义Map工厂只决定最终结果的容器特性，不会自动生成重复值的合并逻辑，合并函数仍然需要你显式定义。

import java.util.LinkedHashMap;

Map orderedBySku = rows.stream()
    .collect(Collectors.toMap(
        PriceRow::sku,
        row -> row,
        (left, right) -> right,
        LinkedHashMap::new
    ));

当同步数据量涨起来之后，不少开发者会直接把普通流stream()改成parallelStream()。官方API明确说明，普通toMap不属于并发Collector；并行管线合并分片生成的多个小Map时，会产生不少额外开销。只有结果完全不依赖流的遍历顺序，且基准测试确认性能瓶颈确实卡在收集阶段时，才考虑评估toConcurrentMap。通常先优化数据读取、对象生成和下游写入逻辑，收益会比直接改成并行流更高。

上线前用这张短表核对

toMap抛出的异常不是问题，它只是在提示你需要给“同一个key对应的两份事实”一个明确的业务定义。把合并规则写在收集点，或者先分组再做后续处理，数据规模持续上涨之后，你依然能追溯到最终结果是怎么生成的。

相关问题

为什么两个参数的 toMap 会报 IllegalStateException？

它默认要求映射生成的key完全唯一。key按equals规则判定重复时，收集过程就会直接抛出异常；如果重复key是预期内的正常输入，应该选择带合并函数的重载实现，或者直接改用groupingBy做分组归集。

用 (left, right) -> right 是不是一定能保留最新数据？

不是绝对的。这个写法只会保留流中后被遍历到的value。只有当输入数据确实严格按版本或时间字段排序，且这个排序规则是明确的业务约定时，才能把“后遍历到”等同于“最新数据”。更稳妥的实现方式是显式比较指定的版本号或者时间字段来选值。

toUnmodifiableMap 也能解决重复 key 的问题吗？

它提供的带合并函数的重载确实可以处理重复key，但这个实现不允许存null key或者null value。只有需要生成不可修改的结果Map时才选择这个实现，同时要把空值边界纳入测试用例。