🟢 Junior Level

Execution begins strictly at the moment a terminal operation is called. Until then, a stream is an inert data structure.

Terminal operations (trigger execution): collect, forEach, count, reduce, findFirst, anyMatch, min, max, sum, toArray

Intermediate operations (do NOT trigger): filter, map, flatMap, sorted, limit, skip, peek

// Nothing happens
Stream<String> stream = list.stream()
    .filter(s -> s.length() > 3)
    .map(String::toUpperCase);

// Only here does work begin
List<String> result = stream.collect(Collectors.toList());

🟡 Middle Level

AbstractPipeline.evaluate() method

When a terminal operation is called, the internal evaluate() method (class AbstractPipeline — the foundation of the Stream API pipeline) does the following:

1. Checks the linkedOrConsumed flag → if true, throws IllegalStateException (stream was already used — streams are one-time-use)
2. Intermediate stages are “collapsed” into a chain of Sink objects — handlers, each of which accepts an element and passes it to the next
3. Determines: sequential or parallel execution
4. Calls spliterator.forEachRemaining(sink) — starts the data traversal loop

Execution triggers

All terminal operations start the process. But not all methods look like terminal:

• count(), sum(), average() — terminal
• toArray() — terminal
• min(), max() — terminal

Resources and onClose

Streams on I/O (Files.lines()) own resources. Close handlers (onClose()) will only fire on explicit close().

Rule: Always use try-with-resources for streams with I/O:

try (Stream<String> lines = Files.lines(path)) {
    lines.filter(...).collect(...);
}

🔴 Senior Level

Short-circuiting execution

Terminal operations like anyMatch or findFirst can complete execution early — the pipeline stops requesting elements as soon as the result becomes obvious. Analogous to break in a for loop. On large data with a selective condition, this saves CPU time since not all elements will be processed.

JIT Warming

The JIT (Just-In-Time JVM compiler) does not compile lambdas to machine code upon their declaration — only after the terminal operation calls them a sufficient number of times (“warmup”). This means: the first few hundred calls run in interpreter mode, which is 5-50 times slower than compiled code. Keep this in mind for benchmarks — use JMH with proper warmup phases.

Edge Cases

Empty Streams: Execution goes through all evaluate stages, but forEachRemaining performs no iterations.

Peek Side Effects: If peek is for logging, and the terminal operation is not called (due to if-else) — logs will not appear. A frequent cause of “phantom bugs”.

Diagnostics

Trace IDs: In distributed tracing (Sleuth/Zipkin), the context (Span) is propagated at the moment of the terminal operation — that is where all CPU load is concentrated.

Stack Traces: On error, the stack trace points to the terminal operation as the entry point — this confuses beginners. The actual error is in one of the intermediate lambdas, but in the stack trace it will be deep inside AbstractPipeline.evaluate().

When NOT to use terminal operations as triggers

• When you need control over execution timing. All terminal operations start the pipeline immediately. If you want to delay execution until a certain condition — do not call the terminal operation prematurely.
• When you need to execute a stream twice. A stream is one-time-use (linkedOrConsumed flag). If you need to process the same data twice — call collect(toList()) to materialize the data, then work with the collection.
• When the source is an external resource without try-with-resources. Files.lines() opens a file descriptor. Without explicit close() (via try-with-resources), the resource will remain open, leading to file descriptor leaks.

---

🎯 Interview Cheat Sheet

Must know:

• Terminal operations (collect, forEach, count, findFirst, anyMatch, etc.) — the only execution triggers
• Before a terminal operation, a stream is an inert data structure, nothing happens
• The AbstractPipeline.evaluate() method checks the linkedOrConsumed flag and builds the Sink chain
• Short-circuit terminal operations (anyMatch, findFirst) can complete the pipeline early
• Streams are one-time-use — reuse will throw IllegalStateException
• I/O streams (Files.lines) must be closed via try-with-resources
• JIT does not compile lambdas until “warmup” — first calls run in interpreter mode
• peek() without a terminal operation — logs will not appear, a frequent source of “phantom bugs”

Frequent follow-up questions:

• Which methods are terminal? — collect, forEach, count, reduce, findFirst, findAny, anyMatch, allMatch, noneMatch, min, max, sum, toArray.
• Why are streams one-time-use? — The linkedOrConsumed flag inside AbstractPipeline prevents reuse — this is an architectural limitation.
• What happens when a terminal operation is called? — evaluate() builds a chain of Sink handlers and launches spliterator.forEachRemaining(sink).
• Why is the stack trace on error confusing? — It points to the terminal operation as the entry point, while the actual error is deep inside an intermediate lambda.

Red flags (DO NOT say):

• “A stream can be reused” — incorrect, it is one-time-use
• “Intermediate operations execute immediately” — incorrect, only from the terminal operation
• “peek() guarantees side effects” — incorrect, only if a terminal operation is present
• “Files.lines() closes the file itself” — incorrect, try-with-resources is needed

Related topics:

• [[21. What is lazy evaluation in Stream]]
• [[24. How does short-circuiting work in Stream]]
• [[25. What are anyMatch(), allMatch(), noneMatch() operations]]
• [[26. What do findFirst() and findAny() operations do]]