Java – peek() actually sees the element flow through a point in the pipeline

My question is expressed in the simplest way:

According to Javadoc:

I have a 10 meter pipe, 3 to 7 meters away from the input head. I have two tags [aka peek()] for checking / debugging my elements

Now I input 1,2,3,4,5 from the input

At x = 4 meters, I have a filter (), which filters all elements less than or equal to 3

Now, according to the Java doc, I should be able to see what happened to my pipeline input at a distance of 3 meters and 7 meters

The output of marker1 distance 3 (. Peek()) should be 1,5, not?? The output of Mark 2 at distance 7 should be significantly 4.5

But this did not happen. The output in the first market (. Peek ()) was only 1 and that in the second market was 4,5

Code I execute to test my theory:

final List<Integer> IntList=
    Stream.of(1,5)
    .peek(it -> System.out.println("Before Filtering "+it)) // should print 1,5
    .filter(it -> it >= 3)
    .peek(it -> System.out.println("After Filtering: "+it)) //should print 4,5
    .collect(Collectors.toList());

Actual output:

Before Filtering 1
Before Filtering 2
Before Filtering 3
After Filtering: 3
Before Filtering 4
After Filtering: 4
Before Filtering 5
After Filtering: 5

Expected output (what should developers think of after reading Javadoc (... Mainly used to support debugging, where you want to see elements flow through a point in the pipeline...)

Before Filtering 1
    Before Filtering 2
    Before Filtering 3
    Before Filtering 4
    Before Filtering 5
    After Filtering: 4
    After Filtering: 5

If Peek () does not just debug at specific points in the pipeline, so DEF is ambiguous

Sorry for my pipe story, I think I can explain the question I want to ask most

Solution

unwanted. You can lazily evaluate flows as needed, and the order of operations is not clearly defined, especially when you peek () This allows the stream API to support very large streams without wasting a lot of time and memory, and allows some implementations to be simplified In particular, a comprehensive evaluation of a single stage of the pipeline is not required before the next stage

Suppose your assumptions are as follows. Suppose how wasteful the following code is:

IntStream.range(1,1000000).skip(5).limit(10).forEach(System::println);

The stream starts with a million elements and ends with 10 If we fully evaluate each stage, our intermediates will be 1 million, 99995 and 10 elements respectively

As a second example, the following streams cannot be evaluated one stage at a time (because intstream.generate returns an infinite stream):

IntStream.generate(/* some supplier */).limit(10).collect(Collectors.toList());

Your pipeline does pass each element through the first peep, and then only a subset through the second peep However, the pipeline performs this evaluation in the order of element main rather than phase main: it evaluates the pipeline as 1, places it at the filter, and then 2 Once the evaluation pipeline is 3, it passes through the filter, so both peek at the statement execution, and then 4 and 5