> Java > Advanced Java Features > Master Stream Operations: Decoding Lazy Evaluation and Pipeline Execution

Advanced Java Features

Master Stream Operations: Decoding Lazy Evaluation and Pipeline Execution

Master Stream Operations: Decoding Lazy Evaluation and Pipeline Execution

Java's Stream API revolutionizes data processing, offering a declarative, functional approach to collections. Yet, many developers grapple with the fundamental distinction between its operational components. Understanding the intricate dance of intermediate and terminal stream operations unlocks profound efficiency and performance gains.


This deep dive forges a path through the core mechanics of stream processing, illuminating how these operations orchestrate the execution pipeline. We dissect the critical concept of lazy evaluation, a cornerstone of Stream API's optimization, revealing how it minimizes computation and maximizes resource utilization. From constructing robust data pipelines to triggering their efficient execution, we engineer a clear understanding of each operation type's role.


Prepare to activate your mastery of Stream API paradigms. Decode the architectural elegance that drives high-performance Java applications and elevate your code quality. Our journey through intermediate and terminal operations provides the strategic insights necessary to fully leverage the power of modern Java's functional capabilities.

Published on:

Forge the Foundations: Understanding Stream Operation Categories

The Java Stream API empowers developers to process sequences of elements with exceptional efficiency and readability. It introduces a paradigm shift from imperative loops to a declarative, functional style. At its core, the Stream API divides operations into two fundamental categories: intermediate and terminal. Grasping this distinction is paramount for designing robust and performant data pipelines.


A stream operation pipeline initiates with a source – typically a collection, an array, or an I/O channel – from which elements are extracted. We then chain a series of intermediate operations, which transform or filter the stream without consuming its elements. This chaining builds a logical blueprint for computation. Crucially, this blueprint remains dormant until a terminal operation activates it, triggering the actual processing of elements. Without a terminal operation, no computation occurs.


This architectural choice ensures that streams are not merely fancier collections but dynamic conduits for data flow. They facilitate internal iteration, where the API manages the traversal, freeing us from explicit loop control. Understanding this mechanism allows us to engineer solutions that are not only concise but also inherently optimized for both sequential and parallel execution. This foundational insight positions us to decode the powerful concept of lazy evaluation.

/*
 * Java Stream API Introduction:
 * A stream is a sequence of elements supporting sequential and parallel aggregate operations.
 * It's not a data structure itself; it operates on a source (e.g., Collection, array).
 * Streams do not change the original data source.
 */

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class StreamOperationsOverview {

    public static void main(String[] args) {
        // Example 1: Basic stream pipeline combining intermediate and terminal operations
        List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "David", "Eve");

        System.out.println("--- Stream Pipeline Example ---");
        List<String> filteredAndMappedNames = names.stream() // Source
            .filter(name -> name.startsWith("A")) // Intermediate operation: filters elements
            .map(String::toUpperCase) // Intermediate operation: transforms elements
            .limit(1) // Intermediate operation: short-circuits, takes only first element
            .collect(Collectors.toList()); // Terminal operation: triggers execution, collects results

        System.out.println("Filtered and Mapped Names: " + filteredAndMappedNames);
        // Expected Output: [ALICE]

        // Example 2: Demonstrating stream reusability (or lack thereof)
        // Streams can only be consumed once.
        System.out.println("\n--- Stream Reusability Example ---");
        var streamToReuse = names.stream();

        long count = streamToReuse.count(); // Terminal operation 1
        System.out.println("Count after first terminal op: " + count);

        try {
            // This will throw an IllegalStateException because the stream has already been operated upon or closed.
            // streamToReuse.forEach(System.out::println); // This line would fail
        } catch (IllegalStateException e) {
            System.out.println("Attempting to reuse stream resulted in: " + e.getMessage());
        }

        // To perform another operation, we must create a new stream from the source.
        System.out.println("Creating a new stream for further operations.");
        names.stream().map(String::length).forEach(len -> System.out.print(len + " "));
        System.out.println();
    }
}

Engineer Intermediate Operations: Crafting the Lazy Pipeline

Intermediate operations are the architectural building blocks of a Stream pipeline. They transform a stream into another stream, enabling sequential processing steps. Crucially, these operations exhibit lazy evaluation – they do not execute until a terminal operation requests a result. This design principle is a potent optimization, preventing unnecessary computation by processing elements only when absolutely required.


Each intermediate operation produces a new stream, allowing for fluent chaining. Common examples include filter() for selecting elements, map() for transforming them, distinct() for removing duplicates, and sorted() for ordering. Some intermediate operations are stateless, meaning each element can be processed independently (e.g., filter, map). Others are stateful (e.g., distinct, sorted), requiring knowledge of previously processed elements or even the entire stream to produce their output, which can impact performance, especially with parallel streams.


A key feature of lazy evaluation in intermediate operations is short-circuiting. Operations like limit() or findFirst() can stop processing elements as soon as their condition is met, preventing the traversal of the entire source. This selective processing dramatically boosts efficiency. We must strategically chain these operations, placing filtering steps early in the pipeline to reduce the number of elements passed to subsequent, potentially more expensive, transformations. This proactive structuring minimizes computational load and maximizes throughput.

/*
 * Intermediate Operations:
 * - Return a new Stream.
 * - Are lazy: they don't perform any actual processing until a terminal operation is invoked.
 * - Can be chained together to form a pipeline.
 * - Are categorized as stateless or stateful.
 *
 * Stateless: filter(), map(), peek(), distinct() (often implemented efficiently),
 *            limit(), skip(). Each element is processed independently.
 * Stateful: sorted(), distinct() (when requiring memory of past elements),
 *           requires full stream traversal or buffering before emitting results.
 */

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class IntermediateOperations {

    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        System.out.println("--- Chaining Intermediate Operations ---");

        // Example: Chaining filter, map, and distinct. Note the 'peek' for visualization.
        List<Integer> processedNumbers = numbers.stream()
            .filter(n -> {
                System.out.println("Filtering: " + n);
                return n % 2 == 0;
            }) // Intermediate: filters even numbers
            .map(n -> {
                System.out.println("Mapping: " + n);
                return n * 2;
            }) // Intermediate: doubles each number
            .distinct() // Intermediate: ensures unique results (stateful operation often)
            .peek(n -> System.out.println("After distinct: " + n)) // Intermediate: useful for debugging
            .sorted() // Intermediate: sorts the numbers (stateful operation)
            .limit(3) // Intermediate: short-circuits, takes only first 3 elements (stateless)
            .collect(Collectors.toList()); // Terminal: triggers the pipeline

        System.out.println("\nFinal Processed Numbers: " + processedNumbers);
        // Expected output will show interleaved 'Filtering' and 'Mapping' due to lazy evaluation.
        // E.g., Filtering: 1, Filtering: 2, Mapping: 2, After distinct: 4, Filtering: 3, Filtering: 4, Mapping: 4, After distinct: 8, ...
        // Notice how 'distinct' and 'sorted' might cause more elements to be processed before 'limit' applies.
        // Output will vary based on exact stream implementation and JIT optimizations, but lazy nature is key.
        // For exact order, careful tracing with `peek` is essential.

        // Consider a small example to highlight lazy evaluation with 'peek' clearly
        System.out.println("\n--- Lazy Evaluation with limit() and peek() ---");
        Arrays.asList("apple", "banana", "apricot", "grape", "avocado", "cherry").stream()
            .filter(s -> {
                System.out.println("  Filtering (starts with 'a'): " + s);
                return s.startsWith("a");
            })
            .map(String::toUpperCase)
            .peek(s -> System.out.println("  After map: " + s))
            .limit(2) // Short-circuits the pipeline after 2 elements are found
            .forEach(s -> System.out.println("  Final result: " + s)); // Terminal operation

        // Observe how 'grape' and 'cherry' are never filtered or mapped because limit(2) is reached earlier.
    }
}

Activate Terminal Operations: Consuming the Pipeline for Results

Terminal operations are the catalysts that ignite the entire Stream pipeline, transforming the conceptual blueprint into concrete results. Unlike intermediate operations, which return another stream, a terminal operation produces a non-stream result or a side-effect. This distinction is critical: without a terminal operation, no elements are processed, and the intermediate pipeline remains inert.


When a terminal operation is invoked, it triggers the execution of all preceding intermediate operations. The elements flow through the defined pipeline, undergo transformations, and finally culminate in the result specified by the terminal operation. This result can take many forms: a new collection (collect()), a single aggregated value (reduce(), sum(), max()), a boolean indicating a match (anyMatch(), allMatch()), or even a side-effect without a direct return value (forEach()).


A key property of terminal operations is that they consume the stream. Once a terminal operation executes, the stream is considered closed or consumed, and it cannot be reused for further operations. Attempting to do so will result in an IllegalStateException. We must ensure that each stream is designed for a single, complete processing sequence. Strategic selection of the appropriate terminal operation dictates the final outcome and directly influences the efficiency of the entire pipeline, especially when combined with short-circuiting intermediate operations.

/*
 * Terminal Operations:
 * - Consume the stream and produce a result (non-Stream value or side-effect).
 * - Trigger the actual execution of the entire stream pipeline (including all intermediate operations).
 * - A stream can only have one terminal operation and can be consumed only once.
 */

import java.util.Arrays;
import java.util.List;
import java.util.Map;
import java.util.Optional;
import java.util.Set;
import java.util.stream.Collectors;

public class TerminalOperations {

    public static void main(String[] args) {
        List<String> words = Arrays.asList("apple", "banana", "apricot", "grape", "avocado", "cherry", "blueberry");

        System.out.println("--- Terminal Operations in Action ---");

        // 1. forEach: performs an action for each element (side-effect)
        System.out.print("forEach (printing elements): ");
        words.stream()
            .filter(s -> s.length() > 5) // Intermediate
            .forEach(s -> System.out.print(s + " ")); // Terminal
        System.out.println();

        // 2. collect: gathers elements into a collection or summary
        List<String> longWords = words.stream()
            .filter(s -> s.length() > 5)
            .collect(Collectors.toList()); // Terminal: into a List
        System.out.println("Collected long words: " + longWords);

        Set<Character> firstLetters = words.stream()
            .map(s -> s.charAt(0)) // Intermediate
            .collect(Collectors.toSet()); // Terminal: into a Set (unique first letters)
        System.out.println("Collected first letters (Set): " + firstLetters);

        Map<Integer, List<String>> wordsByLength = words.stream()
            .collect(Collectors.groupingBy(String::length)); // Terminal: grouping by length
        System.out.println("Words grouped by length: " + wordsByLength);

        // 3. reduce: combines elements into a single result
        Optional<String> concatenated = words.stream()
            .reduce((s1, s2) -> s1 + "-" + s2); // Terminal: combines into a single string
        concatenated.ifPresent(s -> System.out.println("Reduced (concatenated): " + s));

        int sumOfLengths = words.stream()
            .mapToInt(String::length) // Intermediate (specialized for int)
            .sum(); // Terminal (specialized for IntStream)
        System.out.println("Sum of lengths: " + sumOfLengths);

        // 4. count: returns the number of elements
        long countAWords = words.stream()
            .filter(s -> s.startsWith("a"))
            .count(); // Terminal
        System.out.println("Count of words starting with 'a': " + countAWords);

        // 5. findFirst / findAny: returns an Optional describing an element (short-circuiting)
        Optional<String> firstLongWord = words.stream()
            .filter(s -> s.length() > 6) // Intermediate
            .findFirst(); // Terminal (short-circuits)
        firstLongWord.ifPresent(s -> System.out.println("First word longer than 6 chars: " + s));

        // 6. allMatch / anyMatch / noneMatch: returns a boolean (short-circuiting)
        boolean allStartWithA = words.stream()
            .allMatch(s -> s.startsWith("a")); // Terminal (short-circuits)
        System.out.println("All words start with 'a': " + allStartWithA);

        boolean anyContainsZ = words.stream()
            .anyMatch(s -> s.contains("z")); // Terminal (short-circuits)
        System.out.println("Any word contains 'z': " + anyContainsZ);
    }
}

Decode Lazy Evaluation: The Core of Pipeline Optimization

Lazy evaluation is the technological heart of the Java Stream API's efficiency. It mandates that operations are only performed when their results are actually needed by a terminal operation. This contrasts sharply with eager evaluation, where each operation on a collection would produce an entirely new collection, potentially leading to wasteful intermediate data structures.


With lazy evaluation, intermediate operations don't process elements immediately. Instead, they build a chain of transformations. When a terminal operation is invoked, the stream engine processes elements one by one, pushing each element through the entire pipeline of intermediate operations before moving to the next element. This vertical processing, rather than horizontal (processing all elements for one operation, then all for the next), is highly optimized. It allows for techniques like fusion, where multiple operations can be combined and executed in a single pass over the data.


The most compelling benefit of lazy evaluation is its integration with short-circuiting. Operations such as limit(), findFirst(), anyMatch(), allMatch(), and noneMatch() are designed to stop processing as soon as a definitive result can be determined. For instance, if findFirst() identifies the first matching element, the stream immediately ceases iterating over the remaining elements. This dramatically reduces computational overhead, especially on large or infinite streams. Mastering lazy evaluation empowers us to engineer highly efficient and resource-conscious data processing solutions.

/*
 * Lazy Evaluation and Pipeline Execution Order:
 * - Operations are performed on demand, element by element, rather than full-pass per operation.
 * - This means an element goes through the entire chain of intermediate operations before the next element is processed.
 * - Short-circuiting operations (e.g., limit, findFirst, anyMatch, allMatch, noneMatch) exploit lazy evaluation
 *   to stop processing as soon as a result can be determined.
 */

import java.util.Arrays;
import java.util.List;
import java.util.Optional;
import java.util.stream.Collectors;

public class LazyEvaluationDeepDive {

    public static void main(String[] args) {
        List<String> items = Arrays.asList("A1", "B2", "A3", "C4", "A5", "D6", "A7");

        System.out.println("--- Visualizing Lazy Evaluation with peek() ---");

        // Example 1: Standard pipeline, showing interleaved execution
        List<String> processedItems = items.stream()
            .peek(s -> System.out.println("  Source element: " + s)) // Observe source elements
            .filter(s -> {
                System.out.println("    Filtering: " + s);
                return s.startsWith("A");
            })
            .map(s -> {
                System.out.println("      Mapping: " + s);
                return s.toLowerCase();
            })
            .collect(Collectors.toList()); // Terminal operation activates

        System.out.println("Final processed items: " + processedItems);
        // Expected output shows A1, then filter, then map, then B2, then filter (returns false),
        // then A3, then filter, then map, etc. This is the essence of lazy, vertical execution.

        System.out.println("\n--- Lazy Evaluation and Short-Circuiting with findFirst() ---");

        // Example 2: Short-circuiting with findFirst(). Notice not all elements are processed.
        Optional<String> firstFound = items.stream()
            .peek(s -> System.out.println("  Source element for findFirst: " + s))
            .filter(s -> {
                System.out.println("    Filtering for findFirst (length > 2): " + s);
                return s.length() > 2; // Only B2, C4, D6 (and A1, A3, A5, A7 pass for startsWith("A"))
            })
            .map(s -> {
                System.out.println("      Mapping for findFirst (to UpperCase): " + s);
                return s.toUpperCase();
            })
            .findFirst(); // Terminal short-circuiting operation

        firstFound.ifPresent(s -> System.out.println("First item found: " + s));
        // Observe that only elements until the condition for findFirst is met are fully processed.
        // 'A1' -> filter (true) -> map (A1). Result found, pipeline stops. No B2, A3 etc. processed through map.

        System.out.println("\n--- Lazy Evaluation and Short-Circuiting with limit() ---");

        // Example 3: Short-circuiting with limit(). Processing stops once the limit is reached.
        List<String> limitedItems = items.stream()
            .peek(s -> System.out.println("  Source element for limit: " + s))
            .filter(s -> {
                System.out.println("    Filtering for limit (starts with A): " + s);
                return s.startsWith("A");
            })
            .map(s -> {
                System.out.println("      Mapping for limit (appending '-X'): " + s);
                return s + "-X";
            })
            .limit(2) // Intermediate short-circuiting operation
            .collect(Collectors.toList()); // Terminal operation

        System.out.println("Limited items: " + limitedItems);
        // Observe that elements after the second 'A' item are not fully processed through the pipeline.
        // Processing stops after two 'A' items have successfully passed through map and limit.
    }
}

Optimize Stream Performance: Best Practices and Common Pitfalls

Optimizing Java Stream pipelines demands a strategic approach to operation placement and an understanding of underlying performance characteristics. One paramount best practice involves filtering early. Placing filter() operations as close to the stream source as possible drastically reduces the number of elements that subsequent, potentially more CPU-intensive, map() or other transformations must process. This directly leverages lazy evaluation, minimizing wasted computation.


Another crucial consideration is the judicious use of stateful intermediate operations like sorted() or certain custom distinct() implementations, especially when contemplating parallel streams. While the JDK's built-in stateful operations are generally optimized for parallelism, custom stateful operations can introduce significant overhead due to the need for internal buffering and synchronization. Prioritize stateless operations wherever possible to maintain optimal parallel performance and predictable behavior.


Avoid common pitfalls: never reuse a stream once a terminal operation has been invoked; create a new stream from the source if further processing is needed. Be selective with forEach(); it's designed for side-effects and generally less efficient for collecting results than collect(). Furthermore, for numeric operations, favor primitive specialized streams (IntStream, LongStream, DoubleStream) over generic Stream<Integer> to circumvent the performance cost of boxing and unboxing primitive types. By adhering to these principles, we engineer pipelines that are not only readable but also deliver peak performance.

/*
 * Best Practices and Common Pitfalls:
 * - Place filtering operations early in the pipeline to reduce data size for subsequent operations.
 * - Avoid stateful intermediate operations with parallel streams unless strictly necessary and handled carefully.
 * - Understand when to use specific terminal operations (e.g., forEach for side-effects vs. collect for new data structures).
 * - Do not reuse streams.
 * - Be mindful of boxing/unboxing with primitive streams (IntStream, LongStream, DoubleStream).
 */

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public class StreamOptimization {

    public static void main(String[] args) {
        List<String> data = Arrays.asList("apple", "banana", "apricot", "grapefruit", "avocado", "blackberry", "cherry");

        System.out.println("--- Optimization: Filter Early ---");
        // Good Practice: Filter early to reduce elements for subsequent map operations
        List<String> optimizedResult = data.stream()
            .filter(s -> {
                System.out.println("  Filtering (starts with 'a'): " + s); // Processed for all elements
                return s.startsWith("a");
            })
            .map(s -> {
                System.out.println("    Mapping (to UPPERCASE): " + s); // Only processed for filtered elements
                return s.toUpperCase();
            })
            .collect(Collectors.toList());
        System.out.println("Optimized Result: " + optimizedResult);

        System.out.println("\n--- Pitfall: Inefficient Ordering (for demonstration, generally avoid) ---");
        // Bad Practice (for illustration): Mapping before filtering increases mapping operations
        List<String> inefficientResult = data.stream()
            .map(s -> {
                System.out.println("  Inefficient Mapping (to UPPERCASE): " + s); // Processed for ALL elements
                return s.toUpperCase();
            })
            .filter(s -> {
                System.out.println("    Inefficient Filtering (starts with 'A'): " + s); // Processed for ALL mapped elements
                return s.startsWith("A");
            })
            .collect(Collectors.toList());
        System.out.println("Inefficient Result: " + inefficientResult);

        System.out.println("\n--- Parallel Stream with Stateful Operation (Potential Issue) ---");
        // Example: distinct() is stateful. While Java handles it for parallel streams,
        // other custom stateful ops can lead to non-deterministic results or performance degradation.
        List<Integer> numbersWithDuplicates = Arrays.asList(1, 2, 3, 2, 4, 1, 5, 3);
        List<Integer> distinctParallel = numbersWithDuplicates.parallelStream()
            .distinct()
            .sorted()
            .collect(Collectors.toList());
        System.out.println("Distinct (parallel) and sorted numbers: " + distinctParallel);
        // Java's distinct() and sorted() are engineered for parallelism. Custom stateful ops require careful design.

        System.out.println("\n--- Using Primitive Streams for Performance ---");
        // Using IntStream to avoid boxing/unboxing overhead for numeric operations
        int sum = IntStream.rangeClosed(1, 100)
            .filter(n -> n % 2 == 0)
            .sum(); // Terminal operation for IntStream
        System.out.println("Sum of even numbers from 1 to 100: " + sum);

        // Best practice: Avoid side-effects in intermediate operations.
        // Use peek() only for debugging/logging, not for modifying state.
        System.out.println("\n--- Best Practice: Avoid Side-Effects ---");
        List<String> debuggedList = data.stream()
            .peek(s -> System.out.println("  Debugging element (peek): " + s)) // Good for debugging
            .filter(s -> s.length() > 5)
            .map(String::toUpperCase)
            .collect(Collectors.toList());
        System.out.println("Debugged list (no side-effects from peek): " + debuggedList);

    }
}

Key Takeaways

Intermediate vs. Terminal Operations

Intermediate Operations: Forge the pipeline. They return a Stream, are lazy (don't execute until needed), and can be chained. Examples: filter(), map(), distinct(), sorted(), peek(). They build the 'what to do' blueprint.


Terminal Operations: Activate the pipeline. They consume the stream, produce a non-Stream result (or side-effect), and trigger the execution of all preceding intermediate operations. A stream can only be consumed once. Examples: forEach(), collect(), reduce(), count(), findFirst(), allMatch(). They dictate the 'when and how' to get the final result.

Lazy Evaluation & Pipeline Execution

Lazy evaluation is the core optimization: operations execute element-by-element, vertically through the pipeline, only when a terminal operation demands a result. This avoids creating unnecessary intermediate collections and minimizes computation. Short-circuiting operations (e.g., limit(), findFirst()) leverage this by stopping processing as soon as a result is known, dramatically boosting efficiency, especially with large datasets.

Key Best Practices & Pitfalls

Best Practices:

  • Filter early: Reduce the number of elements for subsequent, potentially costly, operations.
  • Use primitive streams: For numeric data (IntStream, LongStream) to avoid boxing/unboxing overhead.
  • Avoid side-effects: Intermediate operations should ideally be pure functions. Use peek() only for debugging.
  • Understand statefulness: Be cautious with stateful operations, especially in parallel streams.

Common Pitfalls:

  • Stream reuse: A stream cannot be reused after a terminal operation.
  • Inefficient ordering: Placing expensive transformations before effective filters.
  • Overuse of forEach(): For collecting results, collect() is generally more efficient and idiomatic.
Editorial Team
← Harness Parallel Streams: Unlock Peak Java Data Processing Conquer Java Generics: Wildcards, Extends, Super, and PECS Mastery →

FAQ

  • What happens if I don't use a terminal operation on a Java Stream?

    If you don't invoke a terminal operation on a Java Stream, nothing happens. The stream pipeline, consisting of intermediate operations, remains a declarative blueprint. No elements are processed, no computations are performed, and no output is generated. The stream simply sits idle, waiting for activation by a terminal operation.

  • Can I reuse a Java Stream after a terminal operation?

    No, you cannot. Once a terminal operation is invoked on a stream, the stream is considered consumed and closed. Any subsequent attempt to use that stream will result in an IllegalStateException. If you need to perform multiple distinct operations, you must create a new stream from the original data source for each sequence of operations.

  • How does lazy evaluation improve performance in Java Streams?

    Lazy evaluation improves performance by ensuring that operations are only performed when their results are explicitly required by a terminal operation. It enables two key optimizations: minimal computation (only processing elements that contribute to the final result) and short-circuiting (stopping processing early when a definitive result is found, as with limit() or findFirst()). This avoids the overhead of creating intermediate collections and performing unnecessary work.

  • When should I use `forEach()` versus `collect()` as a terminal operation?

    Use forEach() when your primary goal is to perform a side-effect for each element, such as printing to the console or modifying an external data structure. It does not return a value. Use collect() when you need to gather the elements of the stream into a new data structure (e.g., a List, Set, Map) or to produce a single summary result (e.g., concatenation, averaging). collect() is generally preferred for producing new data.

  • What's the difference between stateless and stateful intermediate operations?

    Stateless intermediate operations (e.g., filter(), map()) process each element independently, without needing information about other elements in the stream. They are highly efficient, especially in parallel contexts. Stateful intermediate operations (e.g., distinct(), sorted()) require knowledge of previously encountered elements or the entire stream to produce their result. This often necessitates internal buffering or multiple passes, which can impact performance, particularly in parallel streams, due to synchronization overhead.