ParallelStream.collect()必须用线程安全的收集器，否则会抛ConcurrentModificationException；JDK内置收集器如toList()在并行流中通过分段收集+合并实现安全，但自定义Collector需确保combiner线程安全；parallelStream默认使用共享的ForkJoinPool.commonPool()，易导致资源争用，I/O密集型任务应改用CompletableFuture+自定义线程池。
ParallelStream.collect() 必须用线程安全的收集器
并行流不是自动帮你同步结果的。直接用 ArrayList::new 和 ArrayList::add 会抛 ConcurrentModificationException，因为多个线程同时往同一个 ArrayList 写。JDK 提供的 Collectors.toList() 看似简单，但它底层用的是非线程安全的 ArrayList，**仅在串行流中安全**；并行流下它内部做了分段收集+合并，所以能用——但这是特例，不能推广到自定义收集器。
实操建议：
- 优先用
Collectors.toList()、Collectors.toSet()、Collectors.toMap()等 JDK 内置收集器，它们已适配并行场景 - 若需定制结构（如返回
LinkedList或带初始容量的ArrayList），改用Collectors.collectingAndThen()包装线程安全收集过程 - 自己写
Collector时，必须确保combiner函数可被任意线程并发调用，且能正确合并两个中间容器
parallelStream() 的 ForkJoinPool 默认共享全局公共池
所有未指定线程池的 parallelStream() 都跑在 ForkJoinPool.commonPool() 上。这意味着：一个耗时长的并行流（比如读大文件+解析）会阻塞其他模块的并行操作，甚至拖慢整个应用的响应。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 本地测试快，上线后某些接口突然变慢，日志显示
ForkJoinPool.commonPool-worker-*线程长时间 RUNNABLE - 两个无关业务共用 parallelStream，其中一个卡住导致另一个超时
实操建议：
- 对 I/O 密集或不确定耗时的操作，别用
parallelStream()，改用CompletableFuture.supplyAsync()配合自定义ThreadPoolExecutor - 真要用并行计算（CPU 密集），且需隔离资源，可临时切换线程池：
ForkJoinPool pool = new ForkJoinPool(4);<br>pool.submit(() -> list.parallelStream().map(...).collect(...)).join();
- 注意：
parallelStream()不接受外部线程池参数，只能靠ForkJoinPool.managedBlock()或手动 fork/join 模拟
并行流不是总比 for 循环快
小数据量（比如 String::length）、或对象创建开销大的场景，parallelStream 反而更慢——线程调度、分段、合并的成本压过了并行收益。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
性能影响关键点：
- 数据源类型：数组（
int[]、List）分段高效；LinkedList或自定义Spliterator实现不佳时，分割成本高 - 操作复杂度：如果
map里有数据库查询或 HTTP 调用，并行只会放大连接池争用和超时风险 - JVM 预热：首次调用 parallelStream 可能触发 JIT 编译延迟，微基准测试要预热多次
实操建议：
- 用
JMH对比for/stream().sequential()/parallelStream()，不要凭经验猜测 - 监控实际运行时的
ForkJoinPool.commonPool().getActiveThreadCount()，确认是否真在并行执行 - 避免在循环体内反复调用
list.parallelStream()，提取成一次流式处理
异常传播机制和 forEach 的陷阱
parallelStream 中若某个线程抛出未捕获异常，整个流会立即终止，但异常可能被吞掉——尤其在 forEach() 中。它不会像 forEachOrdered() 那样按顺序抛出，也不保证第一个异常就是最终抛出的那个。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
-
parallelStream().forEach(...)里 try-catch 了，但上游异常没被捕获，程序静默失败 - 用
peek()打日志调试时，发现日志顺序乱、数量少，误判逻辑没执行
实操建议：
- 用
map()+collect()替代forEach()，把副作用转为纯函数式转换，异常自然向上冒泡 - 必须用
forEach()且需容错？改用Arrays.stream(array).parallel().forEachOrdered()（仅限数组），或自行用CompletableFuture.allOf()控制异常聚合 - 调试时优先用
forEachOrdered()，它牺牲并行性但保证顺序和异常可见性
最易被忽略的一点：parallelStream 的「并行」只作用于数据处理阶段，不解决数据源本身的线程安全问题。比如对一个正在被其他线程修改的 ArrayList 调用 parallelStream()，即使收集器安全，遍历过程仍可能抛 ConcurrentModificationException。
