Why should stream pipelines be side-effect-free, and what breaks if you mutate external state from map()/filter()?

• Stream operations should be pure: no mutating external state.
• Parallel risk: concurrent mutation of shared state is a data race.
• Sequential risk: peek may be skipped, filter may run unexpectedly many times.
• Correct model: produce results through collectors/reductions, not external mutation.
• Side-effect freedom is what makes streams safely parallelizable and refactorable.

Why must stream lambdas be side-effect-free?

• The Streams API reserves the right to:
• Process elements in any order.
• Split them across threads (parallel).
• Skip operations (peek with count in Java 9+).
• Short-circuit (findFirst, anyMatch).

All of these assume that map and filter lambdas are pure functions: they depend only on their input and produce their output without touching external state.

What breaks when you mutate external state?

package com.bank.hr;

import java.math.BigDecimal;
import java.util.*;
import java.util.concurrent.atomic.AtomicInteger;

public class SideEffectDanger {

    record Employee(String id, String name, BigDecimal salary) {}

    public static void main(String[] args) {
        List<Employee> staff = List.of(
            new Employee("SAV2001", "Rajesh",  new BigDecimal("1800000")),
            new Employee("SAV2002", "Priya",   new BigDecimal("1200000")),
            new Employee("SAV2003", "Meera",   new BigDecimal("1500000"))
        );

        // WRONG: mutating external state from map
        List<String> names = new ArrayList<>();
        BigDecimal[] runningTotal = {BigDecimal.ZERO};

        staff.parallelStream().map(e -> {
            names.add(e.name());                          // race condition!
            runningTotal[0] = runningTotal[0].add(e.salary()); // race condition!
            return e.name();
        }).toList();

        System.out.println("Names (unsafe): " + names);
        System.out.println("Total (unsafe): " + runningTotal[0]);

        // CORRECT: use collectors and reductions
        List<String> safeNames = staff.parallelStream()
            .map(Employee::name)
            .toList();
        BigDecimal safeTotal = staff.parallelStream()
            .map(Employee::salary)
            .reduce(BigDecimal.ZERO, BigDecimal::add);

        System.out.println("Names (safe): " + safeNames);
        System.out.println("Total (safe): " + safeTotal);
    }
}

Names (unsafe): [Meera, Rajesh]  ← wrong count, race condition
Total (unsafe): 3000000          ← may be wrong due to race
Names (safe): [Rajesh, Priya, Meera]
Total (safe): 4500000

How is side-effect-free different from immutable?

| Concept | Meaning |
|---|---|
| Side-effect-free lambda | Does not modify external state; depends only on input |
| Immutable object | Object whose state cannot change after construction |
| Pure function | Side-effect-free + deterministic (same input always gives same output) |

What are common mistakes?

Mistake: Using peek for business logic instead of debugging.

// WRONG: peek for business logic (may be skipped in Java 9+)
staff.stream()
    .peek(e -> auditLog.record(e))  // may not execute!
    .count();

// CORRECT: use forEach for actions, collect for data
staff.stream().forEach(e -> auditLog.record(e));
long count = staff.stream().count();

What breaks specifically in parallel?

• In parallel, mutating shared non-thread-safe state from map or filter is a data race:
• ArrayList.add from multiple threads corrupts the list.
• Incrementing a counter loses updates.
• Accumulating a BigDecimal produces wrong totals.

What is the correct alternative?

• Express outcomes through collectors and reductions:
• Collecting names: map(name).collect(toList()).
• Summing salaries: map(salary).reduce(ZERO, BigDecimal::add).
• Counting: count() or counting() collector.

What should a senior engineer know?

Side-effect freedom is a correctness requirement, not a style preference. It is what lets you safely add .parallel(), reorder operations, or change the terminal without affecting results. Pure functions in map and filter are a design contract with the stream framework.

What are common interview follow-up questions?

• "Can you mutate state in forEach?" forEach is a terminal operation designed for side effects, so yes. But prefer collect when building a result.
• "Is peek safe for logging?" Only for debugging. Java 9+ may skip it.
• "Why does parallel make it worse?" Concurrent mutation of non-thread-safe state is a data race.