Why must lambdas in a parallel stream be pure, stateless, and non-interfering, and what goes wrong if they aren't?

## Setup: what parallel streams actually do Calling `.parallel()` (or `collection.parallelStream()`) asks the Streams framework to run your pipeline concurrently. Mechanically it: 1. **Splits** the source into pieces using a **Spliterator** (a splittable iterator that can hand off half its elements). 2. Runs the intermediate operations on each piece **on different threads** of the common **ForkJoinPool** (a shared thread pool sized to the CPU count by default). 3. **Combines** the partial results back into one (for reductions/collectors). This is the fork/join 'divide and conquer' model. It only produces correct results if the per-element work obeys three rules. ## The three required properties - **Stateless**: an operation is stateless if its result for an element depends *only on that element*, not on any state that changes during the run (a counter, a previously-seen value, a shared accumulator). `map(x -> x*2)` is stateless. A lambda that increments a shared `int count` is **stateful** and unsafe. - **Non-interfering**: the lambda must not modify the *source* of the stream while the pipeline runs. Adding to or removing from the very list you're streaming over is interference and typically throws `ConcurrentModificationException` (even sequentially). - **Pure / side-effect-free**: ideally the lambda produces no observable side-effect at all — no writing to external collections, fields, files, or counters. (Side-effects aren't *forbidden* outright for sequential streams, but they're discouraged, and in parallel they're a correctness hazard unless the target is properly thread-safe.) '**Pure**' is the umbrella term: a pure function returns the same output for the same input and changes nothing outside itself. Pure lambdas automatically satisfy stateless + non-interfering + side-effect-free. ## What goes wrong when you violate this Consider the wrong way to collect results in parallel: ```java List<Integer> out = new ArrayList<>(); // NOT thread-safe IntStream.range(0, 1_000).parallel() .forEach(i -> out.add(i)); // shared-mutable side-effect == BUG ``` Multiple threads call `out.add` simultaneously. `ArrayList` is not synchronized, so you can get: - **Lost updates** — `out` ends up with fewer than 1000 elements because two threads wrote the same slot. - **Corruption exceptions** — `ArrayIndexOutOfBoundsException` or `NullPointerException` from inside ArrayList's resize, because its internal size/array got into an inconsistent state. - **Nondeterminism** — different counts on different runs; passes in tests, fails in prod. A shared `int count` incremented in a lambda has the classic **read-modify-write race**: `count++` is not atomic, so increments are lost. Modifying the source mid-stream yields `ConcurrentModificationException`. ## The correct way: reductions and collectors Instead of mutating shared state, you **reduce**: express accumulation as a combinable operation the framework can split and merge safely. - `reduce(identity, accumulator, combiner)` needs an **identity** (a neutral starting value, e.g. 0 for sum), an **associative** accumulator (grouping doesn't change the result: (a+b)+c == a+(b+c)), and a **combiner** to merge partial results. Associativity is what makes parallel merging valid. - `collect(Collectors.toList())` / `groupingBy` use a `Collector` that the framework runs per-partition into separate containers and then merges, so no shared mutable container is touched by multiple threads. ```java List<Integer> out = IntStream.range(0, 1_000).parallel() .boxed() .collect(Collectors.toList()); // safe, framework-managed long sum = IntStream.range(0, 1_000).parallel().sum(); // safe associative reduction ``` Here each thread accumulates into its own container/partial and the framework merges — no races. ## When is parallel even worth it (the senior+ judgment) Purity is the *correctness* precondition; performance is a separate question. Parallel streams help only when: the data set is large, the per-element work is non-trivial, the source splits cheaply (arrays/ArrayList split well; LinkedList and IO-bound sources split poorly), the operation is associative, and you're not paying heavy boxing. They also share the **common ForkJoinPool** with the rest of the JVM, so a blocking or long task in a parallel stream can starve unrelated parallel work. Often a plain sequential stream or loop is faster and always simpler. Levels: senior = states the three rules, shows the ArrayList race, and uses reduce/collect instead; principal = reasons about associativity/identity, Spliterator split quality, common-pool contention, and whether parallelization actually pays off versus its hazards.