开发经理：谁在项目里面用Stream. paraller()直接gun

大家好，我是小玺，今天给大家分享一下项目中关于Stream.parallel() 碰到的坑。

Stream.parallel() 是Java 8及以上版本引入的Stream API中的一个方法，它用于将一个串行流转换为并行流。并行流可以在多个处理器上同时执行操作，从而显著提高对大量数据进行处理的性能。

踩坑日记

某个大型项目，晚上十一点多有个用户对小部分数据进行某项批量操作后，接口大半天没有反应最后返回超时报错，但是过了一段时间后，出现了部分数据被修改成功，部分数据则没有反应。用户立马跳起来，打电话投诉到公司领导层，于是乎领导层对上至开发经理和PM，下至小开发进行会议批斗，要求马上排查并解决问题，毕竟项目这么大，当初也是要求测试做过压测的，怎么出现这么大的生产事故。

于是乎开发和实施运维分头行事，开发人员排查问题，实施人员先把问题数据维护好，不能应该用户使用。一群开发也是很疑惑，开发和测试环境都没法复现出问题，简单过一下代码也没看出个所以然，由于时间问题，不得不呼叫一手开发经理帮忙看看，开发经理后台接口看完Stream.parallel()进行的操作代码立马就炸了，git看了下提交人【会笑】,把这个开发从头到脚喷了一遍。

在对会笑单独进行了长达半小时的“耐心教育”后(ps:问题安排另一名开发同事修复)，开发经理给团队的所有后端开发人员又都教育了一遍。原来会笑在用并行流的时候，没有考虑线程池配置和事务问题，把一堆数据进行了批量更新，Stream.parallel()并行流使用的是ForkJoinPool.commonPool()作为线程池，该线程池默认最大线程数就是CPU核数。

雀食对于一些初中级开发来说，开发过程中往往喜欢用一些比较新颖的写法来实现但是对新语法又是一知半解的，Stream.parallel()作为Java的新特性，也就成了其中一个反面教材。如果操作数据量不大的情况，其实没有必要用到Stream.parallel()，效率反而会变差。

注意事项

1. 线程安全：并行流并不能保证线程安全性，因此，如果流中的元素是共享资源或操作本身不是线程安全的，你需要确保正确同步或使用线程安全的数据结构。
2. 数据分区：Java的并行流机制会自动对数据进行分区，但在某些情况下，数据分区的开销可能大于并行带来的收益，特别是对于小规模数据集。
3. 效率考量：并非所有的流操作都能从并行化中受益，有些操作（如短流操作或依赖于顺序的操作）并行执行反而可能导致性能下降。而且，过多的上下文切换也可能抵消并行带来的优势。
4. 资源消耗：并行流默认使用的线程池大小可能与机器的实际物理核心数相适应，但也可能与其他并发任务争夺系统资源。
5. 结果一致性：并行流并不保证执行的顺序性，也就是说，如果流操作的结果依赖于元素的处理顺序，则不应该使用并行流。
6. 事务处理：在涉及到事务操作时，通常需要避免在并行流中直接处理，如上述例子所示，应当将事务边界放在单独的服务方法内，确保每个线程内的事务独立完成。

Tips：线程数可以通JVM启动参数-Djava.util.concurrent.ForkJoinPool.common.parallelism=20进行修改