这是 依赖 于 实现的 限制。对于并行性能的关注，开发人员必须了解的一件事是，可预测的流大小通常有助于并行性能，因为它们可以平衡工作负载。
这里的问题是，通过
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, 1000randoms with limit -1, 9223372036854775807range 100, 100range map100, 100range filter -1, 100range limit -1, 100generate 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还是会避免使用。
