对于并行流上的skip（），是否存在一个好的用例？

Question

2015年2月，当我最初问这个问题时，链接问题中报告的行为是违反直觉的，尽管规范允许（尽管文档中存在一些小的不一致）。

然而，塔吉尔·瓦列夫在2015年6月提出了一个新问题，我认为他清楚地证明了这个问题中报告的行为实际上是一个bug。Brain Goetz回答了他的问题，并承认，当由一个终端操作触发时，在skip（）上不停止流的无序特征的反向传播是一个错误，该操作不必强制遵守元素的遭遇顺序（例如forEach（））。此外，在他自己回答的评论中，他分享了一个链接，指向JDK错误跟踪系统中发布的问题。

该问题的状态现已解决，其修复版本为9，这意味着该修复程序将在JDK9中可用。然而，它也已被反向移植到JDK8更新60，构建22。

所以从JDK8u60-b22开始，这个问题就不再有意义了，因为现在skip（）根据直觉行事，即使在并行流上也是如此。

我最初的问题如下。。。

最近我和一些同事讨论了这个问题。我说在并行流上使用skip（）是毫无用处的，因为似乎没有一个好的用例。他们告诉我性能提升、FJ池处理、jvm可用的内核数量等等，但是他们不能给我任何关于其使用的实际例子。

对于并行流上的skip（）？

看到这个问题了吗。请阅读问题和答案，以及评论，因为这里有很多好的论点。




Answer 1

顺序与并行的选择只是执行策略之一。并行性选项的存在使得，如果问题的具体情况（问题大小、流操作的选择、每个元素的计算量、可用处理器、内存带宽等）允许，那么通过并行可以获得性能优势。并不是所有这些细节的组合都会带来性能上的好处（有些甚至可能会受到惩罚），所以我们让用户单独指定操作和执行策略。

对于像skip（）或limit（）这样本质上与遭遇顺序相关的操作，确实很难提取大量并行性，但这是可能的；这通常发生在每个元素的计算功（通常称为“Q”）非常高的情况下。

这种情况可能很少（这可能是你的观点）；这并不意味着操作和执行模式的组合“无用”，只是用处有限。但是，人们不会基于你能想象的有用组合来设计一个具有多个维度（操作、执行模式）的应用编程接口；假设每个组合都有一个明智的语义学（在这种情况下确实如此），最好允许所有模式下的所有操作，让用户决定哪个对他们有用。