Immutability & Thread Confinement

## The core idea **Thread confinement** says: the easiest way to make data thread-safe is to never share it. If exactly one thread ever reads or writes a piece of data, there can be no race condition and no visibility problem, so you need no locks, no `volatile`, nothing. The hazard in concurrency is *shared mutable state*; confinement removes the *shared* part. ## Three flavors of confinement 1. **Stack confinement** — the automatic, strongest form. Each thread has its own **call stack** (the region of memory holding local variables and parameters for the methods it is currently executing). Another thread cannot reach into your stack. So a local variable is, by construction, touched by only one thread. 2. **Ad-hoc confinement** — a *convention* in the code that a particular object is only ever used by one thread (for example, a GUI framework where only the event-dispatch thread touches widgets). Nothing enforces it; it relies on discipline and is easy to break. 3. **`ThreadLocal<T>`** — a library mechanism giving each thread its **own independent copy** of a value. Reads and writes go to a per-thread slot, so threads never see each other's values. Common for per-thread `SimpleDateFormat`, request context, etc. (but watch for leaks in thread pools). ## Stack confinement in detail For a **primitive local** (`int sum = 0;`), the value lives entirely on the stack. No other thread can possibly read or write it, so it is thread-safe with zero effort — this is why most ordinary method-local computation is automatically safe. For a **local reference** (`List<String> tmp = new ArrayList<>();`), the situation is more nuanced. The *reference variable* is on the stack, but the *object* it points to lives on the shared heap. The object stays confined **only if you never publish it**: you must not - assign it to an instance or static field, - add it to a shared collection, - return it in a way that escapes, or - pass it to another thread (e.g. hand it to an `ExecutorService` task or a callback). As long as the object's reference never leaves the method's stack frame, only the current thread can reach it, so it remains thread-safe even if the object itself is mutable. This is why you can freely use a mutable `StringBuilder` or `ArrayList` as a scratch variable inside a method without synchronization. ## Escape: how confinement is lost An object **escapes** when a reference to it becomes reachable outside its intended scope. A subtle case is the `this` reference escaping during construction — e.g. registering a listener or starting a thread inside the constructor — which can publish a half-built object. Confinement and safe construction both depend on preventing escape. ## Why confinement is valuable Confinement gives thread safety with **no locking cost** and no contention. It scales perfectly because there is nothing to coordinate. Its weakness is that, apart from stack-confined primitives, nothing in the language enforces it — it's a discipline the team must maintain and document. ## Relationship to immutability Immutability and confinement are the two main ways to *avoid* shared mutable state (rather than guarding it with locks). Immutability makes sharing safe by forbidding change; confinement makes change safe by forbidding sharing. When neither is possible, you fall back to synchronization plus safe publication.