什么时候该用并行流？先搞懂适用场景
很多人觉得并行流就是把stream()换成parallelStream()这么简单，但实际要不要用、什么时候用，得先看场景。我见过不少开发者不管三七二十一，只要是集合操作就上并行流，结果反而帮了倒忙。这部分我就结合自己的经验和Java官方的 跟你说清楚并行流的“脾气”。
小数据别瞎并行：线程开销比收益还大
你可能会想：“数据量小也试试呗，万一快了呢？”但实际测试下来，很多时候小数据集用并行流反而更慢。我之前在本地做过一个简单测试：对1000条字符串做“过滤+转大写”的操作，串行流平均耗时2毫秒，并行流反而要5毫秒。为什么？因为并行流背后是Fork/Join框架，它得把任务拆分成小任务、分给不同线程执行，最后再合并结果——这些操作本身就有开销。如果数据量太小，拆分和合并的时间比实际处理数据的时间还长，自然就慢了。
那多少数据量才算“大”？这个没有绝对标准，得看你具体的操作复杂度。一般来说，如果是简单操作（比如数值计算、简单过滤）， 数据量至少在1万条以上再考虑并行流；如果是复杂操作（比如对象转换、业务逻辑处理），可能几千条就有效果。你可以自己做个测试：用System.currentTimeMillis()分别跑串行和并行，对比耗时，这是最直观的方法。
Java官方文档里也提到：“并行流在处理大型数据集和CPU密集型操作时表现最佳”（参考Oracle Java文档，nofollow）。这里的“大型数据集”不是绝对数量，而是“处理单个元素的时间 × 元素数量”这个乘积足够大，大到能抵消线程管理的开销。
CPU密集型任务才是并行流的菜
除了数据量，操作类型也很关键。并行流本质是利用多核CPU并行处理任务，所以CPU密集型任务（比如复杂计算、数据转换）才是它的强项；如果是IO密集型任务（比如数据库查询、网络请求、文件读写），用并行流可能会坑你。
我之前见过一个项目，有人在并行流里调用远程API，结果把第三方接口直接打挂了。为什么？因为IO操作时线程大部分时间在“等待”（等网络响应、等数据库返回），这时候并行流创建的线程都在空转，不仅没提升效率，还浪费资源。更糟的是，Fork/Join框架的公共线程池（ForkJoinPool.commonPool()）默认线程数是CPU核心数，假设你是8核CPU，默认就8个线程。如果每个线程都在等IO，你可能觉得“才8个并发，没事”，但实际项目里可能有多个并行流同时跑，加起来并发就高了。
那IO密集型任务想用并行怎么办？ 用自定义线程池，比如ExecutorService，自己控制线程数量（比如设为CPU核心数的2倍或根据IO延迟调整），而不是依赖并行流的公共线程池。
串行流 vs 并行流：一张表帮你快速判断
为了让你更直观地判断什么时候用并行流，我整理了一张对比表，你可以保存下来参考：
| 判断维度 | 优先用串行流 | 优先用并行流 | 注意事项 |
|---|---|---|---|
| 数据量 | ＜1万条（简单操作） | ＞1万条（简单操作） ＞1千条（复杂操作） |
实测对比耗时 |
| 操作类型 | IO密集型（查库、网络请求） | CPU密集型（计算、转换） | IO密集可用自定义线程池 |
| 是否有状态 | 有共享可变状态 | 无状态（纯函数操作） | 避免修改外部变量 |
说明
：表格里的数据量只是参考，具体还得看你的操作复杂度。比如处理1万条字符串做简单过滤，和处理1万条对象做复杂业务计算，适合的流类型可能完全不同。
从踩坑到优化：并行流实战技巧全解析
知道了什么时候用并行流，接下来就得搞清楚“怎么用才不出问题”。我见过太多开发者把并行流用成“麻烦流”，不是性能拉胯就是数据出错。这部分我结合自己踩过的坑和项目经验，跟你说清楚最容易踩的坑和对应的优化技巧。
最容易踩的3个坑：别让并行流变成“麻烦流”
坑点1：用线程不安全的集合收集结果，数据直接“消失”
你可能会写这样的代码：创建一个ArrayList，然后用并行流的forEach往里面加元素。比如：
List result = new ArrayList();
list.parallelStream()
.filter(s -> s.startsWith("a"))
.forEach(result::add); // 危险！
我之前在项目里见过有人这么写，结果每次运行result的大小都不一样，有时甚至少了一半数据。为什么？因为ArrayList的add()方法不是线程安全的——多个线程同时往里面加元素时，可能会覆盖彼此的操作，或者触发ConcurrentModificationException。
正确做法
：用Stream的收集器（Collector），比如Collectors.toList()。你可能不知道，Collectors.toList()在并行流下会自动用线程安全的方式收集结果（它会先让每个线程处理自己的子列表，最后合并）。实测下来，上面的代码改成collect(Collectors.toList())后，数据就再也没丢过：
List result = list.parallelStream()
.filter(s -> s.startsWith("a"))
.collect(Collectors.toList()); // 安全！
坑点2：修改共享可变状态，结果“随机”出错
除了收集结果，如果你在并行流里修改外部的共享变量，也会出大问题。比如统计符合条件的元素数量，有人会这么写：
int count = 0;
list.parallelStream()
.filter(s -> s.length() > 5)
.forEach(s -> count++); // 危险！
运行后你会发现，count的值总是比实际少——因为count++其实是“读取-修改-写入”三步操作，多线程下会有竞争。我之前帮人调试过一个类似的问题，明明有1000个符合条件的元素，结果count有时是800，有时是900，完全随机。
正确做法
：用Stream的reduce或collect方法，它们是为并行流设计的，能安全处理聚合操作。比如上面的代码可以改成：
long count = list.parallelStream()
.filter(s -> s.length() > 5)
.count(); // 安全！
如果是复杂的聚合逻辑，用reduce更灵活。记住：并行流下，尽量让操作无状态——不要读取或修改流外部的变量，让每个元素的处理都是独立的。
坑点3：忽略并行度，线程“抢资源”导致性能下降
并行流默认用的是ForkJoinPool.commonPool()，它的并行度（线程数）默认是Runtime.getRuntime().availableProcessors()
（CPU核心数减1）。但你知道吗？如果项目里有多个并行流同时跑，它们会共享这个公共线程池。我之前遇到过一个项目，后台定时任务和接口请求同时用了并行流，结果线程池被占满，任务排队，接口响应时间直接从50ms涨到500ms。
举个例子
：假设你的服务器是4核CPU，公共线程池默认3个线程。如果同时有3个并行流跑CPU密集型任务，每个任务都需要1个线程，刚好够用；但如果有5个并行流同时跑，就会有2个任务排队等待，反而拖慢整体速度。
优化三板斧：让并行流性能起飞的实战技巧
技巧1：合理调整并行度，别让线程“打架”
如果你发现公共线程池不够用，或者线程太多导致资源竞争，可以手动调整并行度。有两种方法：
方法一
：全局设置公共线程池的并行度。通过系统属性java.util.concurrent.ForkJoinPool.common.parallelism设置，比如启动JVM时加参数：
-Djava.util.concurrent.ForkJoinPool.common.parallelism=4或者在代码里设置：
System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "4");方法二
：用自定义ForkJoinPool执行并行流。如果只是某个并行流需要特殊的并行度，可以自己创建线程池：
ForkJoinPool pool = new ForkJoinPool(4); // 4个线程
pool.submit(() -> {
list.parallelStream()
.forEach(element -> {
// 处理逻辑
});
}).get();
pool.shutdown();
我之前在一个8核服务器上，把公共并行度从默认的7调到5，留2个核心给其他关键任务，结果系统整体响应时间降低了20%。你可以根据服务器CPU核心数和任务类型调整，CPU密集型任务并行度 设为核心数或核心数+1，IO密集型可以更高（但并行流不适合IO密集，前面说过啦）。
技巧2：避免共享状态，让每个线程“独立工作”
并行流的性能杀手之一就是“共享可变状态”——多个线程争着修改同一个变量，会导致大量的线程切换和锁竞争。我之前优化过一个接口，里面用并行流处理数据时，有个步骤是更新一个共享的HashMap。后来我把逻辑改成每个线程处理自己的子Map，最后合并，接口耗时直接从300ms降到120ms。
具体怎么做
：
map代替修改外部变量：每个元素的处理都返回新结果，而不是修改外部对象。collect的combiner合并结果：自定义Collector时，确保combiner能正确合并多个线程的中间结果（参考Oracle Collector文档，nofollow）。String、Integer这些不可变类型，避免线程间干扰。技巧3：用好Spliterator，让任务拆分更“聪明”
并行流能高效处理数据，离不开Spliterator（可分割迭代器）——它负责把数据集拆分成小任务，分给不同线程。如果你的数据结构是ArrayList、HashSet这些标准集合，Spliterator已经优化得很好了；但如果是自定义集合，或者用Stream.generate()创建的流，Spliterator可能拆分得不均匀，导致有的线程很忙，有的很闲（“负载不均衡”）。
比如我之前遇到过一个自定义链表，它的Spliterator每次只能拆分成“一个元素”和“剩下的元素”，结果并行流跑起来，一个线程处理了80%的数据，其他线程几乎没事干，性能还不如串行流。后来重写了Spliterator，让它能平均拆分数据，并行效率直接提升了3倍。
怎么判断Spliterator好不好
？你可以用Spliterator.estimateSize()看看它能不能预估元素数量，用trySplit()看看拆分是否均匀。如果你的并行流性能不理想，不妨检查一下数据集的Spliterator实现。
如果你之前在并行流上踩过坑，或者用了这些技巧后性能有提升，欢迎在评论区告诉我你的经历！毕竟并行流这东西，光看理论不如实际动手试试——多测试、多对比，才能真正用得得心应手。
判断要不要用并行流处理数据，其实不用死记硬背规则，我教你几个我平时干活儿会看的点，你照着套就行。先看数据量，这玩意儿得结合你要做的操作复杂度来定。就拿我之前处理用户列表来说吧，要是只是简单过滤一下“手机号以138开头的用户”，这种操作特别快，数据量少于1万条的时候，我试过用并行流反而比串行慢——你想啊，并行流得把任务拆给好几个线程，处理完了还得合并结果，这点数据量，拆分合并的功夫比实际处理数据的时间还长，纯属瞎折腾。但如果是复杂操作，比如把用户对象转成DTO，还得算个会员等级、积分啥的，那可能三四千条数据用并行流就有效果了，我之前那个项目就是，5000条用户数据转DTO，串行跑了800毫秒，换成并行流直接降到400多，肉眼可见的快。
再看你要干的活儿是“CPU密集”还是“IO密集”，这点特别关键。CPU密集就是那种让CPU一直忙个不停的活儿，比如算个斐波那契数列、处理一堆字符串转大写再排序，这种活儿用并行流就对了，能把多核CPU的劲儿都使上。但要是IO密集型的，比如一边遍历数据一边查数据库、调接口，你可千万别用并行流。我去年帮朋友看代码，他在并行流里调第三方物流接口，想着“多线程快点跑完”，结果呢？100条数据下去，线程池里的线程全在那儿等接口响应，不仅没快，还把人家接口的限流给触发了，直接返回429，得不偿失。这种时候不如自己搞个线程池，控制下并发数，比并行流瞎折腾靠谱多了。
还有个特别容易踩的坑，就是“共享状态”——说白了就是你在并行流里改了外面的变量。我见过有人用并行流遍历数据，然后往一个ArrayList里塞结果，跑起来数据少一半都算好的，严重的时候直接报异常。为啥？因为ArrayList不是线程安全的，多个线程一起往里塞东西，很可能两个线程同时写同一个位置，数据就被覆盖了。所以用并行流的时候，尽量别让它碰外面的变量，要是非改不可，要么用线程安全的容器（比如ConcurrentHashMap），要么就用Stream自带的collect收集器，它会帮你处理线程安全的问题，省心不少。
最后说个最实在的办法：自己跑一遍试试。别光听别人说“多少数据量该用”，不同项目、不同机器配置，情况差远了。你把串行流和并行流的代码都写出来，用System.currentTimeMillis()记个时，跑个三五遍取个平均值，哪个快用哪个。我之前处理一批日志数据，按经验觉得1万条该用并行流，结果实测下来串行更快，后来发现是日志里有大量重复字符串，JVM做了优化，串行处理反而效率更高。所以啊，数据量、操作类型、共享状态这些是参考，自己动手测一测，才是最准的。
并行流和串行流的主要区别是什么？
并行流和串行流的核心区别在于处理方式：串行流通过单线程按顺序处理数据，适合小数据量或简单操作；并行流则利用多线程并行处理，通过Fork/Join框架将任务拆分给多个线程，最后合并结果，适合大数据量和CPU密集型任务。 并行流需要额外的线程管理开销（如任务拆分、合并），而串行流无此开销， 小数据量下并行流可能更慢。
如何判断是否应该使用并行流处理数据？
判断是否使用并行流可从三个维度考虑：一是数据量， 简单操作（如过滤、计算）数据量至少1万条以上，复杂操作（如对象转换、业务逻辑）可降至几千条；二是操作类型，优先用于CPU密集型任务（如数值计算、数据转换），避免IO密集型任务（如数据库查询、网络请求）；三是是否有共享状态，确保操作无状态（不修改外部变量）。最直接的方式是实测对比：用串行流和并行流分别执行任务，通过耗时判断是否适合。
并行流中用ArrayList收集结果为什么会出错？
因为ArrayList的add()方法不是线程安全的。并行流执行时，多个线程会同时调用add()，可能导致线程间操作覆盖（如两个线程同时写入同一位置）或触发ConcurrentModificationException。正确做法是使用Stream提供的收集器（如Collectors.toList()），它在并行流下会自动通过线程安全的方式收集结果（先让每个线程处理子列表，最后合并），避免数据丢失或异常。
并行流的默认线程数是多少？如何调整？
并行流默认使用Fork/Join框架的公共线程池（ForkJoinPool.commonPool()），默认线程数为“CPU核心数-1”（如8核CPU默认7个线程）。调整方式有两种：一是通过系统属性全局设置，启动JVM时添加参数“-Djava.util.concurrent.ForkJoinPool.common.parallelism=N”（N为线程数），或代码中设置System.setProperty(“java.util.concurrent.ForkJoinPool.common.parallelism”, “N”)；二是创建自定义ForkJoinPool，通过pool.submit()执行并行流，灵活控制线程数（如new ForkJoinPool(4)创建4线程池）。
并行流适合处理IO密集型任务吗？
不适合。并行流的优势是利用多核CPU并行处理计算，而IO密集型任务（如数据库查询、网络请求、文件读写）中，线程大部分时间处于等待状态（等待IO响应），此时并行流的线程会空转，不仅无法提升效率，还会因线程管理开销浪费资源。 公共线程池可能被多个并行流占用，导致任务排队阻塞。处理IO密集型任务 使用自定义ExecutorService线程池，根据IO延迟调整线程数（如CPU核心数的2-4倍），更灵活控制资源。
