应使用collect替代foreach+外部集合，通过collectors.tolist()等声明式收集器实现线程安全；避免lambda中修改非final变量、调用有状态操作或修改原始集合。
直接避免在并行 Stream 的 lambda 中操作非线程安全集合，核心是**不写共享写逻辑，改用声明式收集**。并行流的 forEach、peek 等终端操作若涉及 ArrayList.add()、HashMap.put() 等，本质是多线程竞争修改同一对象，必然引发数据丢失、越界或 ConcurrentModificationException。
用 collect 替代 forEach + 外部集合
这是最常用也最推荐的方式。把“先创建空集合 → 多线程往里塞”这种命令式思路，改为“让流自己负责分段收集再合并”的声明式做法：
- ✅ 正确：使用 Collectors.toList()、Collectors.toSet()、Collectors.groupingBy() 等内置收集器，它们内部基于 ForkJoin 分治，每个线程操作独立子容器，最后安全合并
- ❌ 错误：手动 new ArrayList()，再在 parallelStream().forEach(...) 里调用 add()
- 示例对比：
好写法：list.parallelStream().map(String::toUpperCase).collect(Collectors.toList())
坏写法：List<string> result = new ArrayList(); list.parallelStream().forEach(s -> result.add(s.toUpperCase()));</string>
需要多次添加时，用 flatMap 合并多个元素
当一个输入元素要生成多个输出（比如一个 source 要转成 sigma 和 lambda 两个字符串），别在 forEach 里反复 add，而是用 flatMap 将其展开为流，再统一 collect：
-
.flatMap(s -> Stream.of(sigmaString(s), lambdaString(s)))把每个源映射为双元素流 - 后续接
.collect(Collectors.toList())，整个过程无共享变量、无副作用 - 比手动同步或用 synchronizedList 更简洁、更高效、更符合函数式风格
真需自定义收集逻辑？实现 Collector 接口
内置收集器不够用时（例如要收集到 TreeSet、或做带状态的聚合），不要退回到外部集合 + 同步块，而应正确定义线程安全的 Collector：
- 实现 Supplier（提供每个线程的局部容器，如 () -> new TreeSet()）
- 实现 BiConsumer（定义如何把元素累加进局部容器）
- 实现 BinaryOperator（定义如何合并两个局部容器）
- Collector 自动适配并行执行模型，无需你处理锁或可见性问题
其他常见误区提醒
除了集合操作，以下行为同样破坏线程安全性，需一并规避：
- 在 lambda 中修改外部非 final 变量（包括普通字段、静态变量）
- 调用有状态的中间操作（如 sorted、distinct）后又依赖顺序——并行下顺序不保证
- 对原始集合本身做结构性修改（如在流处理中 list.remove()），会触发 ConcurrentModificationException
- 用 StringBuilder 拼接字符串：它不是线程安全的，应改用 String.join() 或 Collectors.joining()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
