并发流本身不保证线程安全，风险源于共享可变集合的写操作；应改用collectors.toconcurrentmap()等线程安全收集器，小数据量优先使用串行流。
并发流（parallelStream）本身不提供线程安全保证，它只是把数据拆成多段交给多个线程并行处理。真正决定是否线程安全的，是你在流操作中对共享变量或集合的访问方式——尤其是写操作。
共享可变集合是最大风险点
像 HashMap、ArrayList 这类非线程安全集合，被多个线程同时 put 或 add 时，会发生数据覆盖、扩容冲突甚至 ConcurrentModificationException。你代码里用 result.put(item, item) 往普通 HashMap 写，就是典型高危操作。
- 即使只跑几千次，也可能某次 size 少 1 —— 不是“偶尔出错”，而是“必然可能出错”
- 问题上线后才暴露，是因为并发量、JVM 调度、CPU 核数等环境因素放大了竞争概率
- 本地单线程测试永远正常，掩盖了根本缺陷
推荐的安全写法不是“加锁”，而是“换结构”
避免手动同步，优先用 JDK 原生支持并发收集的 API：
- 用
Collectors.toConcurrentMap()替代手动put：Map<string string> result = list.parallelStream().collect(Collectors.toConcurrentMap(Function.identity(), Function.identity()));</string> - 需要定制 key/value 逻辑？传入
keyMapper和valueMapper即可 - 若需合并重复 key，补充第三个参数
mergeFunction，比如(v1, v2) -> v1 - 其他常用安全收集器：
toSet()、toList()（返回的是线程安全的不可变容器）
串行流往往更简单可靠
除非数据量极大（如百万级以上）且操作耗时（如 JSON 解析、正则匹配），否则并行流未必更快，还增加复杂度：
- 小数据集 + 简单映射（如字符串转 ID）：用
stream().collect(...)足够，性能差异可忽略 - 并行流有分片开销、线程调度成本，数据量小时反而更慢
- 调试困难：并行执行顺序不确定，日志和断点失去意义
- 线上问题复现难，排查成本远高于预防成本
真要用并行流，务必检查三件事
不是所有操作都能并行化，也不是所有结果都适合并行生成：
- 操作必须无状态：不能读写外部变量、不能依赖前一次执行结果
-
数据源要支持高效分片：
ArrayList可以，LinkedList分片代价高，慎用 -
终止操作要是聚合型：优先选
collect、reduce；避免forEach+ 共享变量这种组合
