Java流限制和跳过无序和并行时的行为 [英] Java stream limit and skip behaviour when unordered and parallel

查看:158
本文介绍了Java流限制和跳过无序和并行时的行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

因此,我一直在并行处理正在运行的流,并根据我阅读的API文档和其他支持材料来监视它们的行为.

So I have been playing around with running streams in parallel and monitoring their behaviour based on the API documentation and other supporting material I have read.

我创建了两个并行流并运行distinct(),一个运行流是有序的,另一个运行是无序的.然后,我使用forEachOrdered()打印结果(以确保在运行distinct之后确保看到流的结果遇到顺序),并且可以清楚地看到,无序版本不会保持原始顺序,但是对于大型数据集,显然增强并行性能.

I create two parallel streams and run distinct(), one where the stream is ordered and one where it is unordered. I then print the results using forEachOrdered() (to ensure I see the resulting encounter order of the stream after distinct has run), and can clearly see that the unordered version does not maintain the original ordering, but with a large dataset, would obviously enhance parallel performance.

有一些API注释建议,当流无序时,limit()skip()操作也应更有效地并行运行,因为不必检索第一个n元素,就可以获取任何n元素.我试图以与上述相同的方式对此进行模拟,但是当与有序和无序流并行运行时,结果始终是相同的.换句话说,当我在运行极限之后打印出结果时,即使对于无序(并行)流,它仍然始终是前n个元素的选择?

There are API notes suggesting that the limit() and skip() operations should also run more efficiently in parallel when the stream is unordered as rather than having to retrieve the first n elements, you can get any n elements. I have tried to simulate this in the same way as above, but the result when ran in parallel with both ordered and unordered streams is always the same. In other words, when I print out the result after running limit, even for an unordered (parallel) stream, it has still always picked for first n elements?

有人可以解释吗?我尝试改变输入数据集的大小和n的值,但没有区别.我会以为它将捕获任何n个元素并针对并行性能进行优化?有没有人实际看到这种情况在实践中发生,并且可能提供一种始终如一地展示这种行为的解决方案?

Can anyone explain this? I tried varying the size of my input dataset and the value of n and it made no difference. I would have thought that it would grab any n elements and optimise for parallel performance? Has anyone actually seen this happen in practice, and could possibly provide a solution that showcases this behaviour consistently?

推荐答案

您可能试图从SIZED/SUBSIZED源(例如arrayList.stream()Arrays.stream(array)IntStream.range()等)创建流,并立即发出limitskip操作.此案例在limit/skip实现中经过了特别优化(请参见

You probably tried to create the stream from SIZED/SUBSIZED source (like arrayList.stream(), Arrays.stream(array), IntStream.range(), etc.) and immediately issue limit or skip operation. This case is specially optimized in limit/skip implementation (see SliceOps) and runs with the same speed for both ordered and unordered stream (and actually runs very fast). If you remove such characteristics (for example, adding filtering step), you will see that making the stream unordered after that really helps. Write test like this:

input.stream().parallel().filter(x -> true).skip(..)...
input.stream().parallel().unordered().filter(x -> true).skip(..)...
input.stream().parallel().filter(x -> true).limit(..)...
input.stream().parallel().unordered().filter(x -> true).limit(..)...

或者,您可以使用非SUBSIZED源(例如,TreeSetHashSet)进行测试.

Alternatively you may test with non SUBSIZED source (for example, TreeSet or HashSet).

这篇关于Java流限制和跳过无序和并行时的行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆