parallelStream()本身线程安全，但业务逻辑需满足无状态、无副作用、可结合；误改共享变量、用非线程安全类或不当reduce会导致异常或结果错误。
并行流 parallelStream() 默认不保证线程安全
Java 的 parallelStream() 本身是线程安全的——它能正确启动多个线程、分片数据、合并结果。但「流操作中的业务逻辑」是否线程安全，完全取决于你写的 map、filter、reduce 等中间/终止操作。常见踩坑点包括：
- 在
forEach中直接修改外部ArrayList或HashMap（非并发集合）→ 抛ConcurrentModificationException或数据丢失 - 用静态变量或共享可变对象（如
SimpleDateFormat）做格式化 → 出现乱码、解析失败 - 在
reduce中误用非关联、非结合的操作（如字符串拼接用+=而非String::concat）→ 结果不可预测
哪些操作天然适合并行流
满足「无状态」「无副作用」「可结合」三个条件的操作，才能放心并行。典型安全场景：
-
map中只读取元素并返回新值（如s -> s.toUpperCase()） -
filter中只基于当前元素判断布尔值（如n -> n % 2 == 0） -
reduce使用符合结合律的二元操作（如Integer::sum、String::concat），且提供合法的恒等值（0、""） - 终端操作用
collect(Collectors.toList())—— 它内部会用线程安全的收集方式，但注意：返回的List是普通ArrayList，不是线程安全的
什么时候不该用 parallelStream()
并行 ≠ 更快。小数据量、IO 密集型、或操作本身很轻量时，并行反而拖慢性能：
- 集合大小
- 操作中包含同步块、锁、数据库连接、文件读写 → 实际变成串行，还多出线程切换成本
- 源数据是
LinkedList或自定义Spliterator且无法高效分割 → 分片不均，部分线程空转 - JVM 运行在容器中且未显式配置可用 CPU 数（如
-XX:ActiveProcessorCount=4），默认按物理核数分派线程，可能超配
调试并行流问题的实用技巧
遇到结果不一致或异常，别猜，用工具和日志定位：
立即学习“Java免费学习笔记（深入）”；
- 临时改用
stream()运行对比结果，确认是否为并发引发 - 在关键操作中打印线程名：
map(s -> { System.out.println(Thread.currentThread().getName() + ": " + s); return s; }) - 检查是否误用了非线程安全类：比如
new Date()安全，但new SimpleDateFormat("yyyy-MM-dd")不安全，应换DateTimeFormatter - 用
ForkJoinPool.commonPool().getParallelism()查看当前并行度，避免在测试环境（默认 2 核）和生产（多核）行为不一致
List<String> result = list.parallelStream()
.map(String::toUpperCase)
.filter(s -> s.startsWith("A"))
.collect(Collectors.toList()); // ✅ 安全：无状态、无副作用、使用标准收集器
真正容易被忽略的是：并行流的「安全边界」只到你写的 lambda 表达式内部；一旦它触碰到外部可变状态、静态资源、或阻塞调用，就立刻跳出安全区。别依赖“流本身并发”来掩盖代码设计缺陷。
