这是 依赖 于 实现的 限制。对于并行性能的关注,开发人员必须了解的一件事是,可预测的流大小通常有助于并行性能,因为它们可以平衡工作负载。
这里的问题是,通过Stream.generate()
和创建的无限流的组合limit()
不会产生具有可预测大小的流,尽管它对我们而言似乎是完全可预测的。
我们可以使用以下辅助方法对其进行检查:
static void sizeOf(String op, IntStream stream) {
final Spliterator.OfInt s = stream.spliterator();
System.out.printf("%-18s%5d, %d%n", op, s.getExactSizeIfKNown(), s.estimateSize());
}
然后
sizeOf("randoms with size", ThreadLocalRandom.current().ints(1000));
sizeOf("randoms with limit", ThreadLocalRandom.current().ints().limit(1000));
sizeOf("range", IntStream.range(0, 100));
sizeOf("range map", IntStream.range(0, 100).map(i->i));
sizeOf("range filter", IntStream.range(0, 100).filter(i->true));
sizeOf("range limit", IntStream.range(0, 100).limit(10));
sizeOf("generate limit", IntStream.generate(()->42).limit(10));
将打印
randoms with size 1000, 1000
randoms with limit -1, 9223372036854775807
range 100, 100
range map 100, 100
range filter -1, 100
range limit -1, 100
generate limit -1, 9223372036854775807
因此,我们可以看到,某些来源喜欢Random.ints(size)
或IntStream.range(…)
产生具有可预测大小的流,而某些中间操作map
则可以携带信息,因为他们知道大小不受影响。其他人喜欢filter
并且limit
不传播尺寸(作为已知的准确尺寸)。
显然,filter
无法预测元素的实际数量,但是它提供了源大小作为估计值,这是合理的,因为这是可以通过过滤器的最大元素数量。
相反,limit
即使源具有精确的大小,当前的实现也不提供大小,并且我们知道可预测的大小很简单min(source size, limit)
。取而代之的是,它甚至报告了一个毫无意义的估计大小(源的大小),尽管事实是,结果大小永远不会超过限制。在无限流的情况下,我们还Spliterator
面临其他障碍,即流所基于的接口无法报告它是无限的。在这些情况下,无限的流量+极限Long.MAX_VALUE
作为估计返回,这意味着“我什至无法猜测”。
因此,根据经验,在当前的实现中,程序员应避免limit
在有可能预先在流源处指定所需大小的情况下使用。但是由于limit
在 有序 并行流(不适用于random或generate
)的情况下也具有明显的(已记录的)缺点,因此大多数开发人员limit
还是会避免使用。