使用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()));只要我不关心顺序，使用并行会一直有益吗？有人会认为，更快地将工作划分到更多的内核上。
还有其他考虑事项吗？什么时候应该使用并行流，什么时候应该使用非并行流？
（问这个问题引发了关于如何以及何时使用并行流的讨论，不是因为我认为始终使用并行流是一个好主意。）
Answers:
与顺序流相比，并行流的开销要高得多。协调线程需要大量时间。我将默认使用顺序流，并且仅在以下情况下考虑并行流
我要处理大量项目（或者每个项目的处理需要时间并且可以并行化）
我首先遇到性能问题
我尚未在多线程环境中运行该流程（例如：在Web容器中，如果我已经有许多并行处理的请求，则在每个请求中添加额外的并行度层可能会产生多于积极影响的负面影响）
在您的示例中，无论如何，性能都将受到对的同步访问的驱动System.out.println()，并且使此过程并行将没有效果，甚至没有效果。
此外，请记住，并行流并不能神奇地解决所有同步问题。如果在过程中使用的谓词和函数使用了共享资源，则必须确保所有内容都是线程安全的。尤其是副作用，如果并行使用，那么您真的要担心。
无论如何，不要猜测！只有度量会告诉您并行性是否值得。
Runnable了调用start()它们以用作对象的方式Threads，是否可以将其更改为在.forEach()并行化中使用java 8流？然后，我将能够从类中剥离线程代码。但是有什么缺点吗？
Stream API旨在简化计算方式，简化了计算方式，简化了顺序和并行之间的切换。
但是，仅仅因为它容易，并不意味着它总是一个好主意，实际上，仅仅因为可以就把它放到各处都是一个坏主意.parallel()。
首先，请注意，并行化除了提供更多内核可用时更快执行的可能性外没有其他好处。并行执行总是比顺序执行涉及更多的工作，因为除了解决问题之外，它还必须执行子任务的调度和协调。希望您可以通过分解多个处理器上的工作来更快地找到答案。是否真的发生取决于很多事情，包括数据集的大小，每个元素要进行多少计算，计算的性质（具体来说，一个元素的处理是否与其他元素的处理相互作用？） ，可用处理器的数量以及与这些处理器竞争的其他任务的数量。
此外，请注意，并行性通常还会在计算中暴露出不确定性，而不确定性通常被顺序实现所隐藏；有时这无关紧要，或者可以通过限制所涉及的操作来缓解（即，归约运算符必须是无状态且具有关联性的）。
实际上，并行有时会加快您的计算速度，有时却不会，甚至有时会降低速度。最好先使用顺序执行进行开发，然后在其中应用并行性
（A）您知道提高性能实际上是有好处的，并且
（B）实际上会提供更高的性能。
（A）是业务问题，而不是技术问题。如果您是性能专家，通常可以查看代码并确定（B），但是明智的选择是衡量。（并且，甚至在您确信（A）之前都不要打扰；如果代码足够快，最好将您的大脑循环应用于其他地方。）
并行性的最简单性能模型是“ NQ”模型，其中N是元素数，Q是每个元素的计算量。通常，在开始获得性能优势之前，您需要产品NQ超过某个阈值。对于低Q问题，例如“从1到N的数字相加”，通常会看到N = 1000和N = 10000之间的收支平衡。对于较高Q的问题，您将在较低的阈值处看到收支平衡。
但是现实是相当复杂的。因此，在获得专家见识之前，请先确定顺序处理实际上何时使您付出了代价，然后衡量并行性是否会有所帮助。
findAny而不是findFirst…
myListOfURLs.stream().map((url) -> downloadPage(url))...）。
ForkJoinPool.commonPool()并且您不想阻止任务去那里。
我观看了Brian Goetz （Java语言架构师和Lambda Expressions的规范负责人）的演示之一。他详细解释了进行并行化之前要考虑的以下4点：
拆分/分解成本
–有时拆分比仅做工作要昂贵！
任务分配/管理成本
–可以花很多时间将工作交给另一个线程。
结果合并成本
–有时合并涉及复制大量数据。例如，增加数字很便宜，而合并集合很昂贵。
位置
-房间里的大象。这是每个人都可能错过的重要一点。您应该考虑缓存未命中，如果CPU由于缓存未命中而等待数据，那么并行化将不会带来任何好处。这就是为什么在缓存下一个索引（当前索引附近）时，基于数组的源能够并行处理最佳资源的原因，并且CPU遇到高速缓存未命中的可能性较小。
他还提到了确定并行加速机会的相对简单的公式。
NQ模型：
N x Q > 10000其中，
N =数据项的数量
Q =每个项目的工作量
JB撞到了头。我唯一可以添加的是Java 8不会进行纯并行处理，而是会进行后处理。是的，我写了这篇文章，并且从事F / J工作已经三十年了，所以我确实理解了这个问题。
ArrayList/同样有效HashMap。
其他答案已经涵盖了性能分析以避免并行处理中的过早优化和开销成本。这个答案解释了并行流数据结构的理想选择。
作为一项规则，从并行性能提升是最好的流过
ArrayList，HashMap，HashSet，和ConcurrentHashMap实例; 数组;int范围 和long范围。这些数据结构的共同之处在于，它们都可以准确而廉价地拆分为任意大小的子范围，这使得在并行线程之间划分工作变得容易。流库用于执行此任务的抽象方法是分隔符，该分隔符由spliteratoronStream和方法返回Iterable。所有这些数据结构的共同点的另一个重要因素是，当按顺序进行处理时，它们提供了很好的引用局部性：顺序元素引用一起存储在内存中。这些引用所引用的对象在内存中可能彼此不接近，从而降低了引用的位置。事实证明，引用位置对于并行化批量操作至关重要：没有它，线程将花费大量时间空闲，等待数据从内存传输到处理器的缓存中。具有最佳引用位置的数据结构是原始数组，因为数据本身连续存储在内存中。
来源：第48项，并行使用流时要小心，有效的Java 3e作者：Joshua Bloch
永远不要将无限流与限制并行化。这是发生了什么：
public static void main(String[] args) {
// let's count to 1 in parallel
System.out.println(
IntStream.iterate(0, i -> i + 1)
.parallel()
.skip(1)
.findFirst()
.getAsInt());
}结果
Exception in thread "main" java.lang.OutOfMemoryError
at ...
at java.base/java.util.stream.IntPipeline.findFirst(IntPipeline.java:528)
at InfiniteTest.main(InfiniteTest.java:24)
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.stream.SpinedBuffer$OfInt.newArray(SpinedBuffer.java:750)
at ...如果使用相同 .limit(...)
此处的说明： Java 8，在流中使用.parallel会导致OOM错误
同样，如果流是有序的并且具有比您要处理的元素更多的元素，请不要使用并行，例如
public static void main(String[] args) {
// let's count to 1 in parallel
System.out.println(
IntStream.range(1, 1000_000_000)
.parallel()
.skip(100)
.findFirst()
.getAsInt());
}这可能会运行更长的时间，因为并行线程可能会在大量数字范围内工作，而不是在关键的0-100范围内工作，这将导致很长的时间。