Java 中的 parallelStream 在哪些应用领域有用？

Question

我试图确定一类可以从使用 Java 8 中引入的 parallelStream API 中受益的 Java 应用程序。

我知道其他 SO 帖子中描述的 API 的许多警告：

• 共享 fork/join 池，具有非平凡的启动时间，以及池中争用的一些潜在问题
• 以某种方式不受控制地使用系统资源，使得在服务器（已经具有多任务策略）上使用此类代码实际上可能是一个坏主意
• ...还有其他批评主要与性能有关

尽管如此，如果 Stream API 已经被使用，API 仍然可以使用现代多核机器，代码不是很具有侵入性，因此在低开发成本下没有麻烦的多线程。因此，我仍然认为它在某些情况下很有用。

我认为应用程序上下文因此必须是这样的：

1. 我的申请目前是连续的
2. 存在响应时间问题，就挂钟时间而言，例如，用户单击了 GUI 按钮并正在等待回复
3. 应用程序在客户端机器上运行，大多数时候我们可以期望有一些可用的 CPU 内核，而不是在资源已经竞争的服务器上
4. 我的开发团队没有人力/技能来开发他们自己的任务分配/线程机制，所以他们不会去并行化，除非他们可以使用这个 API 轻松做到

我在github上搜索过，但很难找到不是练习或教科书示例的parallelStream用法的相关示例（我欢迎链接到API的中型+项目中的一些用法）。

那么，Java 语言开发人员使用此 API 的目标是哪种应用程序？

您是否同意上述对 API 有用的应用程序上下文的要求？

Answer 1

在可能的情况下我应该总是使用并行流吗？中提出了类似的问题。注意第二个答案是由 Oracle 的 Java 语言架构师 Brian Goetz 给出的，他参与了 Stream API 的设计，所以他的答案可能被认为是权威的。

最佳答案很快指出，并行流包含协调所需的额外开销，因此只会在每个流的单独处理量足够大以至于并行处理的增益克服初始开销的情况下提高性能。

毫不奇怪，与任何性能问题一样，建议是衡量而不是猜测。从顺序流开始，如果您有大量元素，每个元素都需要复杂的计算，请测量切换到并行流的性能差异。

其他指南（例如 OP 中列出的指南）可能会有所帮助；但众所周知，人们不善于识别性能瓶颈，因此任何指导方针最终在面对实际测量时都可能失败。