本文正在参加「Java主题月 - Java Debug笔记活动」，详情查看活动链接
如果可能，是否应该始终使用并行流？
使用Java 8和lambda，可以很容易地将集合作为流进行迭代，也很容易使用并行流。docs中的两个示例，第二个示例使用parallelStream：
myShapesCollection.stream()
.filter(e -> e.getColor() == Color.RED)
.forEach(e -> System.out.println(e.getName()));
myShapesCollection.parallelStream() // <-- This one uses parallel
.filter(e -> e.getColor() == Color.RED)
.forEach(e -> System.out.println(e.getName()));
只要我不关心顺序，使用并行会总是有好处吗？有人会认为，更快地将工作划分到更多的内核上。
还有其他考虑事项吗？什么时候应该使用并行流，什么时候应该使用非并行？
（问这个问题可以引发关于如何以及何时使用并行流的讨论，不是因为我认为始终使用并行流是一个好主意。）
高分回答：
与顺序流相比，并行流的开销要高得多。协调线程需要花费大量时间。我将默认使用顺序流，并且仅在以下情况下考虑并行流
我要处理大量项目（或者每个项目的处理需要时间并且可以并行化）
我首先遇到性能问题
我尚未在多线程环境中运行该流程（例如：在Web容器中，如果我已经有许多并行处理的请求，则在每个请求中添加额外的并行度层可能会产生多于积极影响的负面影响）
在您的示例中，无论如何，性能都将受到对的同步访问的驱动System.out.println()，并且使此过程并行不会产生影响，甚至不会产生负面影响。
此外，请记住，并行流并不能神奇地解决所有同步问题。如果该过程中使用的谓词和函数使用了共享资源，则必须确保所有内容都是线程安全的。尤其是副作用，如果并行使用，您真的要担心。
无论如何，不要猜测！只有度量会告诉您并行性是否值得。
高分回答：
Stream API旨在简化计算方式，简化了计算方式，简化了顺序和并行之间的切换。
但是，仅仅因为它容易，并不意味着它总是一个好主意，实际上，仅仅因为可以就把它放到整个地方是一个坏主意.parallel()。
首先，请注意，并行化除了在有更多内核可用时更快执行的可能性外没有其他好处。并行执行总是比顺序执行涉及更多的工作，因为除了解决问题之外，它还必须执行子任务的分派和协调。希望您可以通过分散多个处理器的工作来更快地找到答案。这种情况是否真的发生取决于很多因素，包括数据集的大小，对每个元素进行的计算量，计算的性质（具体来说，一个元素的处理是否与其他元素的处理相互作用？） ，可用处理器的数量以及与这些处理器竞争的其他任务的数量。
此外，请注意，并行性通常还会在计算中暴露出不确定性，而不确定性通常会被顺序实现所隐藏。有时这无关紧要，或者可以通过限制所涉及的操作来缓解（即，归约运算符必须是无状态且具有关联性的）。
实际上，并行有时会加快您的计算速度，有时却不会，甚至有时会降低速度。最好先使用顺序执行进行开发，然后在其中应用并行性
（A）您知道提高性能实际上是有好处的，并且
（B）实际上会提供更高的性能。
（A）是业务问题，而不是技术问题。如果您是性能专家，通常可以查看代码并确定（B），但是明智的选择是衡量。 （并且，甚至在您确信（A）之前都不要打扰；如果代码足够快，那么最好将您的大脑循环应用于其他地方。）
并行性最简单的性能模型是“ NQ”模型，其中N是元素数，并且Q是每个元素的计算量。通常，在开始获得性能优势之前，您需要产品NQ超过某个阈值。对于像低Q问题“从加起来的数字1来N”，你会看到一般之间的盈亏平衡N=1000和N=10000。对于较高Q的问题，您将在较低的阈值处看到收支平衡。
但是现实是相当复杂的。因此，在获得专家见识之前，请先确定顺序处理实际上何时使您付出了代价，然后衡量并行性是否会有所帮助。
文章翻译自kgs4h5t57thfb6iyuz6dqtun5y-ac4c6men2g7xr2a-stackoverflow-com.translate.goog/questions/2…
作者建议:没事别滥用并行流
真心感谢帅逼靓女们能看到这里，如果这个文章写得还不错，觉得有点东西的话
求点赞👍 求关注❤️ 求分享👥 对8块腹肌的我来说真的 非常有用！！！
如果本篇博客有任何错误，请批评指教，不胜感激 ！❤️❤️❤️❤️
