为何两段Java Stream代码操作执行次数不同？Limit位置影响解析

你已经理解Stream API的惰性操作和**垂直计算（流水线式处理单个元素）**特性，但Limit方法的位置不同，会导致操作执行次数出现显著差异，以下是具体示例：

代码示例1 #

int sum = IntStream.range(1, 101)
                .map(i -> {
                    System.out.format("map : %d \n",i);
                    return i * i;
                })
                .limit(5)
                .filter(i -> {
                    System.out.format("filter : %d\n",i);
                    return i<20;
                })
                .sum();
System.out.println(sum);

执行结果 #

map : 1 
filter : 1
map : 2 
filter : 4
map : 3 
filter : 9
map : 4 
filter : 16
map : 5 
filter : 25
30

代码示例2 #

int sum = IntStream.range(1, 101)
                .map(i -> {
                    System.out.format("map : %d \n",i);
                    return i * i;
                })
                .filter(i -> {
                    System.out.format("filter : %d\n",i);
                    return i<20;
                })
                .limit(5)
                .sum();
System.out.println(sum);

执行结果 #

map : 1 
filter : 1
map : 2 
filter : 4
...
map : 97 
filter : 9409
map : 98 
filter : 9604
map : 99 
filter : 9801
map : 100 
filter : 10000
30

原因分析 #

1. 代码1的执行逻辑 #

limit(5)是短路操作，它会在从上游拿到5个元素后，立即停止向上游请求更多元素：

• 上游的range(1,101)只生成前5个元素（1-5）
• 每个元素依次经过map和filter处理，总共执行5次map和5次filter
• 最后sum计算符合i<20的4个元素（1、4、9、16）的总和，结果为30

2. 代码2的执行逻辑 #

limit(5)放在filter之后，它需要从filter的输出中拿到5个符合条件的元素，但你的filter条件是i<20（即原数的平方小于20）：

• 整个流中只有原数1、2、3、4的平方（1、4、9、16）满足条件，总共只有4个符合要求的元素
• limit(5)会一直等待第5个符合条件的元素，因此Stream会遍历完range(1,101)的所有100个元素，每个元素都执行map和filter，直到确认没有更多符合条件的元素为止
• 最终sum还是只能拿到那4个符合条件的元素，结果依然是30

总结 #

• limit的短路效果生效的前提是：能从上游获取到足够数量的元素。如果上游的过滤操作大幅减少了有效元素数量，limit凑不够指定数量时，就会遍历完整个流。
• 合理调整操作顺序（比如在业务允许的情况下，将limit放在过滤类操作之前），可以提前终止不必要的元素生成和处理，大幅提升Stream的执行效率。

内容的提问来源于stack exchange，提问作者shining