A lambda needs to accumulate a running total across iterations, but the compiler rejects reassigning a captured local. What are the correct ways to achieve mutable state, and what are the trade-offs?

## The constraint, restated A lambda **captures local variables by value** and only permits **effectively final** locals (assigned once, never reassigned). So `int total = 0; list.forEach(x -> total += x);` does **not compile** — `total += x` reassigns `total`. The key insight: the rule forbids reassigning the *captured variable*, not mutating the *object it points to*. If the captured thing is a reference to a mutable object and that reference never changes, you may change the object's contents all you like. ## The three idiomatic escapes ### 1. One-element array (the 'mutable box' trick) ```java long[] sum = {0}; // the array reference is effectively final list.forEach(x -> sum[0] += x); // mutating sum[0] is fine long total = sum[0]; ``` Works because `sum` (the reference) is never reassigned; only element 0 changes. Terse but cryptic, and **not thread-safe**. ### 2. Atomic holder ```java AtomicLong sum = new AtomicLong(); list.forEach(x -> sum.getAndAdd(x)); long total = sum.get(); ``` `AtomicLong`/`AtomicInteger`/`AtomicReference` are designed mutable holders with **lock-free, thread-safe** updates. Clearer intent than the array and safe under concurrency. Slight overhead vs a plain field. ### 3. Instance field ```java class Accumulator { long sum; void add(int x) { /* lambda body */ this.sum += x; } } ``` Fields are read/written live through the captured `this`, so they bypass the local-capture rule entirely. Good when the state genuinely belongs to the object; otherwise it leaks lambda-internal state onto the class. ## Why none of these are the *best* answer for streams With a **parallel stream**, multiple threads run the lambda simultaneously. The array trick races outright (lost updates, torn reads). Even `AtomicLong` works but serializes on a hot contended counter, killing the parallelism you paid for. The functional-programming-correct solution is a **reduction**: combine values without shared mutable state. ```java long total = list.stream().mapToLong(Integer::longValue).sum(); // built-in reduction long total2 = list.stream().reduce(0, Integer::sum); // explicit reduce ``` Reductions are **associative** and stateless per element, so the framework can split, process partitions independently, and merge — correct and fast in parallel. This is why the Streams API exposes `sum`, `reduce`, and `Collector`s instead of encouraging side-effecting `forEach`. ## Decision guide - Sequential, quick local accumulation, single-threaded, throwaway code → array box or `Atomic*` (prefer `Atomic*` for readability). - Concurrent updates from multiple threads → `Atomic*` or a concurrent collection. - Stream aggregation → a **reduction / collector**, not mutable capture. - State conceptually owned by an object → a field. ## Underlying principle The language nudges you away from shared mutable state because that state is the source of data races and hard-to-reason-about code. The 'effectively final' rule is a small wall that makes you pause and pick an explicit, intention-revealing mechanism instead of silently closing over a mutable local.