When do CountDownLatch and CyclicBarrier fall short, and what would you reach for instead?

## Where the two primitives stop `CountDownLatch` and `CyclicBarrier` are excellent for **fixed, known** coordination, but they share two limits: 1. **Fixed membership** — the count (events for a latch, parties for a barrier) is set at construction and **cannot change**. Real systems sometimes add or remove participants between phases. 2. **Thread-blocking** — `await()` **parks a real thread**. With thousands of coordination points this ties up platform threads that could do work. ## Phaser — dynamic, multi-phase coordination `java.util.concurrent.Phaser` generalises the barrier: - **Dynamic parties**: `register()` adds a party, `arriveAndDeregister()` removes one — so the group can grow and shrink between phases. (Neither latch nor barrier allows this.) - **Many phases**: like a `CyclicBarrier` it advances through numbered phases; `arriveAndAwaitAdvance()` is the per-phase rendezvous. - **`onAdvance(phase, parties)`**: an overridable hook run at each phase boundary (like a barrier action) whose return value can **terminate** the phaser. - **Tiered phasers** reduce contention for very large party counts. Terms: a **phase** is one round of the cycle; **register/deregister** change how many arrivals are needed for the next advance. Use Phaser when the number of collaborators **varies over the run**, or when you want phase-aware termination logic — e.g. a pipeline where stages spin up and retire workers. ## CompletableFuture — non-blocking result fan-in If the real goal is *'do N async things, then continue when all finish'* and you don't need threads to literally wait, **`CompletableFuture.allOf(f1, f2, ...)`** returns a future that completes when all inputs complete — **without blocking** a thread the whole time. It also composes (`thenCompose`, `thenCombine`) and propagates exceptions, which a latch can't. This is usually a better fit than a `CountDownLatch` for asynchronous I/O fan-out. ## Structured concurrency — scoped task groups Modern Java offers **`StructuredTaskScope`** (structured concurrency): you fork subtasks within a scope, then `join()`; the scope **owns** the subtasks, propagates cancellation, and ties their lifetime to a lexical block. For 'wait for all subtasks, cancel the rest on first failure' this is clearer and safer than hand-rolled latches, and it integrates with **virtual threads** so blocking is cheap. ## Virtual threads — softening, not solving **Virtual threads** make blocking on `await()` far cheaper (a parked virtual thread doesn't pin a platform thread), so the *blocking* objection weakens. But virtual threads add **no dynamic-membership** capability — for that you still need Phaser. They make the simple latch/barrier patterns scale better rather than obsolete. ## Decision guide - Fixed one-shot signal / start gate → **CountDownLatch**. - Fixed group, repeated lockstep rounds → **CyclicBarrier**. - **Changing** participant count or phase-aware termination → **Phaser**. - Compose async task **results** without blocking → **CompletableFuture**. - Scoped group of subtasks with unified cancellation → **StructuredTaskScope** (structured concurrency). The principal-level point: pick the **smallest primitive that expresses the actual coordination shape and failure model**, and don't reach for Phaser/structured concurrency when a plain latch is clearer.