Fed*_*ner 1 theory parallel-processing java-8 java-stream
当我最初问这个问题,2015年2月,在报道的行为所链接的问题是反直觉的,但那种规范允许(尽管在文档一些小的矛盾).
然而,Tagir Valeev在2015年6月问了一个新问题,我认为他清楚地证明了这个问题中报告的行为实际上是一个错误.Brain Goetz回答了他的问题,并承认,当一个终端操作触发时,不会阻止on 的特性的反向传播是一个错误,这个终端操作不会被迫尊重元素的遭遇顺序(例如) .此外,在他自己的回答的评论中,他分享了JDK的错误跟踪系统中发布的问题的链接.UNORDEREDStreamskip()forEach()
该问题的状态现已解决,其修复版本为9,这意味着该修复程序将在JDK9中可用.但是,它也被反向移植到JDK8 update 60,build 22.
所以从JDK8u60-b22开始,这个问题再也没有意义了,因为现在skip()表现得像直觉一样,甚至在并行流上也是如此.
我原来的问题是......
最近我和一些同事讨论了这件事.我说skip()在并行流上使用它是没用的,因为它似乎没有一个很好的用例.他们告诉我有关性能提升,FJ池处理,jvm可用的核心数量等等,但他们无法给我任何实际的使用示例.
skip()并行流是否存在良好的用例？
顺序与并行的选择只是执行策略之一.存在并行性的选项,以便如果问题的具体情况(问题大小,流操作的选择,每个元素的计算工作,可用处理器,存储器带宽等)允许,则可以通过并行获得性能益处.并非所有这些细节的组合都会承认性能优势(有些甚至可能会受到惩罚),因此我们将其留给用户,以便从执行策略中单独指定操作.
对于像skip()or或者limit()那些本质上与遭遇顺序相关的操作,确实很难提取很多并行性,但它是可能的; 这通常发生在每个元素的计算工作量(通常称为"Q")非常高时.
这种情况可能很少见(这可能是你的意思); 这不会使操作和执行模式的组合"无用",仅仅是有限的用途.但是,人们不会根据人们可以想象的组合设计具有多个维度(操作,执行模式)的API; 假设每个组合都有一个合理的语义(在这种情况下它会这样做),最好允许所有模式中的所有操作,并让用户决定哪些对它们有用.