What is structured concurrency in Java, and what problem does it solve compared to launching threads or futures manually?

## The problem **Concurrency** means running more than one task at the same time. Traditionally in Java you do this by submitting work to an `ExecutorService` and getting back a `Future` (a handle to a result that isn't ready yet), or by starting raw `Thread`s. This is *unstructured*: once you submit a task, its lifetime is no longer tied to the method that started it. Several things go wrong: - **Thread/task leaks (orphans).** If your method returns or throws before a submitted task finishes, that task keeps running in the background with nobody waiting on it. It is an *orphan* — a thread that outlived the code that created it. - **Swallowed errors.** If task A fails, task B often keeps running pointlessly, and the failure may sit unnoticed inside a `Future` until someone calls `get()`. - **No cancellation propagation.** Cancelling the overall operation does not automatically cancel the in-flight subtasks. - **Hard to read.** The relationship between "the thing I'm doing" and "the helper tasks it spawned" is invisible in the code and in thread dumps. ## Structured programming, applied to threads Decades ago, *structured programming* replaced `goto` with blocks (`if`, `while`, function calls): control flow enters a block at the top and leaves at the bottom, so lifetimes nest cleanly. **Structured concurrency** applies the same principle to concurrent tasks: *if a task splits into concurrent subtasks, they must all complete (or be cancelled) before the parent block exits.* The lifetime of every subtask is **nested** inside the block that created it. ## How Java expresses it: `StructuredTaskScope` Java's API (preview since JDK 21, JEP 453/462/480/505) is the class `StructuredTaskScope`. The pattern is: ```java try (var scope = new StructuredTaskScope<String>()) { Subtask<String> a = scope.fork(() -> fetchUser()); // start subtask Subtask<String> b = scope.fork(() -> fetchOrder()); // start subtask scope.join(); // wait for ALL of them return a.get() + b.get(); // read results } // close() here: guarantees nothing started inside is still running ``` - **`fork(Callable)`** starts a *subtask* on a new (usually virtual) thread and returns a `Subtask` handle. It does **not** block. - **`join()`** blocks the parent until every forked subtask has finished (or the scope's policy decides to stop early). - **try-with-resources** ensures `scope.close()` runs no matter how the block exits — normal return, exception, or otherwise. `close()` is what enforces the structure: it cannot return while any subtask is still alive, so an orphan is impossible. ## Why this is better 1. **No orphans.** The compiler-visible block boundary plus `close()` guarantee every subtask is done before you move on. 2. **Automatic error propagation.** With a shutdown-on-failure policy, if one subtask throws, the scope interrupts the others and `join()` surfaces the error to the parent — you don't have to poll each `Future`. 3. **Cancellation propagation.** Cancelling/interrupting the parent thread propagates down to the children. 4. **Readability and observability.** The code reads like sequential code, and tooling (thread dumps) can show the parent-child tree. ## Virtual threads connection Structured concurrency shines with **virtual threads** (lightweight threads managed by the JVM, cheap enough to have millions). Forking a subtask per unit of work is fine because virtual threads are cheap; the scope keeps their lifetimes disciplined. The two features were designed together. ## Status note The API is a *preview/incubating* feature and its exact shape has evolved across JDK 21–25 (e.g. factory methods, `Joiner` policies). The *concept* — scope-bound lifetimes, fork/join, error and cancellation propagation — is stable and is what interviewers test.