应选Collectors.toConcurrentMap()当需多线程安全构建并频繁读写映射；它返回ConcurrentHashMap，而toMap()返回的HashMap并发写入会出错。
什么时候该用 Collectors.toConcurrentMap() 而不是 Collectors.toMap()
当你明确需要在多线程环境下安全地构建一个映射（比如并行流处理后直接收集，或多个线程各自调用 collect() 合并结果），且后续会频繁读写该映射——这时才考虑 toConcurrentMap()。它返回的是 ConcurrentHashMap 实例，而 toMap() 默认返回普通 HashMap，并发写入会抛 ConcurrentModificationException 或产生数据丢失。
注意：parallelStream().collect(Collectors.toMap(...)) 本身是线程安全的（因为收集过程由框架协调），但如果你手动把多个并行子流的结果传给 toConcurrentMap() 做合并，或后续要让多个线程持续读写这个 map，那才真正需要它的并发能力。
toConcurrentMap() 的三个重载版本怎么选
最常用的是三参数版本：toConcurrentMap(keyMapper, valueMapper, mergeFunction)。它强制你提供冲突处理逻辑，避免 key 重复时失败。
- 两参数版本（
keyMapper,valueMapper）：只适用于“能确保 key 绝对不重复”的场景，否则运行时报IllegalStateException: Duplicate key - 三参数版本：推荐默认使用。例如去重取最新值：
(oldVal, newVal) -> newVal；或累加：(a, b) -> a + b - 四参数版本：可指定
ConcurrentMap构造函数（如ConcurrentHashMap::new）和并发级别（concurrencyLevel）。一般不用显式设concurrencyLevel，除非你知道预估的写线程数远高于默认值（16）
并行流 + toConcurrentMap() 的典型误用
常见错误是以为写成 list.parallelStream().collect(Collectors.toConcurrentMap(...)) 就“自动更高效”了。其实不然：
- 并行流对小数据集（比如
-
toConcurrentMap()内部仍需处理 key 冲突，如果冲突率高（比如大量相同 key），mergeFunction会被频繁调用，反而拖慢速度 - 如果只是想“最终得到一个
ConcurrentHashMap”，完全可以用Collectors.toMap()+ 手动构造：new ConcurrentHashMap(list.stream().collect(Collectors.toMap(...)))，省去并发控制开销
真正适合的场景是：数据源本身已分片（如多个 ForkJoinTask 独立产出子 map），再用 toConcurrentMap() 合并——这时它能利用 ConcurrentHashMap.putAll() 的批量优化。
键冲突时的 mergeFunction 怎么写才不出错
这个函数必须满足结合律和无副作用，否则并发下结果不可预测。比如：
- ✅ 安全：
(a, b) -> a + b、(a, b) -> Objects.equals(a, b) ? a : b、(old, _new) -> _new - ❌ 危险：
(a, b) -> { list.add(a); return b; }（有外部状态）、(a, b) -> a.toString().length() > b.toString().length() ? a : b（非结合：(a,b),c 和 a,(b,c) 可能不同） - ⚠️ 注意：如果 value 是可变对象（如
StringBuilder），不要直接修改oldVal，应创建新实例，否则可能被其他线程同时读取到中间状态
实际中建议优先用不可变类型做 value，或确保 mergeFunction 返回新对象而非复用旧引用。
并发 map 的“高效”不来自函数名，而来自你是否真需要并发写入、是否压低了冲突率、是否避开了不必要的并行开销。多数业务场景里，先用 toMap() + 显式包装成 ConcurrentHashMap 更可控，也更容易调试。
