CountDownLatch.

Interviewers love CountDownLatch because it tests whether you can coordinate threads without overcomplicating the design.

Question: What is CountDownLatch in Java, and when would you use it?

Answer: CountDownLatch is a synchronization tool that lets one or more threads wait until a set of work items finishes. You create it with a fixed count, call countDown() as each task completes, and call await() in the waiting thread. It is one-time use: once the count reaches zero, it stays open forever.

Interview-Ready Answer: I use CountDownLatch when I want one thread to wait for several other tasks to finish before continuing, like waiting for three service calls or worker threads during startup. I initialize it with the number of completions I need, have each worker call countDown() in a finally block, and have the coordinator call await(). A nice detail is that it provides a memory-visibility guarantee: work done before countDown() becomes visible after a successful await(). The key limitation is that it is one-shot, so if I need something reusable, I would look at CyclicBarrier or Phaser.

What it is

CountDownLatch is a simple gate. Think of a room with a locked door and a counter on the wall. Each task finishes, presses the button once, and when the counter hits zero the door opens.

How it works under the hood

1. You create it with a fixed count, such as new CountDownLatch(3). That number is stored internally as shared state.
2. One or more threads call await(). If the count is still above zero, they block, which means the thread stops running and waits in the scheduler queue.
3. Each worker calls countDown() when its job is done. If this call reduces the count to zero, the latch releases all waiting threads.
4. When await() returns successfully, the waiting thread can safely continue. Java also gives a happens-before guarantee, meaning earlier writes in the worker threads become visible to the waiting thread.
5. If a worker throws an exception, the latch does not decrement automatically. That is why countDown() usually belongs in a finally block.

When and why to use it

Use it when the flow is one-way: start here, wait for N completions, then continue. Common examples are application warmup, parallel data fetches, and tests that need multiple threads to finish before assertions run. Do not use it when you need to reuse the same coordination point many times.

Comparisons

Performance and edge cases

The basic operations are effectively O(1): countDown() and await() do a tiny amount of bookkeeping, then park or release threads as needed. Memory cost is small, because the latch stores only the count and waiting state. Common edge cases are forgetting a countdown, waiting forever, or using the latch after it already reached zero and assuming it can be reset. It cannot. If you need a timeout, use await(timeout, unit) so the system can fail fast instead of hanging forever.

Memory hook: “A latch is a one-way door: each task turns one key, and the last key opens it forever.”

Real-world story

Imagine a checkout service that starts three warmup jobs in parallel: load promo rules, fetch payment config, and prime the product cache. The main server thread uses a CountDownLatch to wait until all three jobs finish before accepting traffic.

What goes wrong: one warmup task throws an exception before calling countDown(). Startup never finishes, the service sits “healthy but not ready,” and logs show the main thread stuck in await(). In production, this looks like a deployment that never opens traffic, repeated readiness probe failures, and frustrated operators seeing no clear error unless the timeout path is in place.

Follow-up & Tricky Questions:

• How is CountDownLatch different from CyclicBarrier? CountDownLatch is one-way and one-time; CyclicBarrier is reusable and designed for a group of threads to all wait at the same point before moving on.
• What happens if countDown() is called more times than the initial count? Nothing bad happens after it reaches zero; the count stays at zero and extra calls have no further effect.
• Why should countDown() usually be in a finally block? Because exceptions can skip normal code paths. Putting it in finally ensures the latch is released even when the task fails.
• Can one latch be reused for another batch? No. Once open, it stays open. Create a new latch for each batch or phase.
• What does await(timeout, unit) return? It returns true if the latch reached zero in time, otherwise false. That is crucial for building safe startup or retry logic.
• Do waiting threads consume CPU while blocked? No, they park. That means they are not spinning and burning CPU cycles while they wait.
• Can countDown() unblock multiple waiting threads? Yes. Once the count hits zero, all threads waiting in await() are released.

Tricky questions:

• Does CountDownLatch track which thread counted down? No, it only tracks the count. Any thread can call countDown().
• Is it a replacement for synchronized? No. synchronized protects shared data; CountDownLatch coordinates progress between threads.
• If a worker finishes before the main thread calls await(), is that a problem? No. The count is already lower, so the later await() returns immediately once the count is zero.

Common Mistakes:

• Forgetting a countdown on failure. Fix: put countDown() in finally.
• Using it as reusable coordination. Fix: use CyclicBarrier or Phaser for repeated phases.
• Blocking forever with plain await(). Fix: use a timeout in production paths.
• Expecting it to protect shared state. Fix: use proper thread-safe data structures or locks for data safety.

Memory Hook: One-way door: every task turns one key, and the last key opens the gate forever.

Cheat Sheet:

• Construct with a fixed count.
• Workers call countDown(); waiters call await().
• One-shot only; no reset.
• Use finally to avoid deadlocks from exceptions.
• Use await(timeout, unit) for safety.
• Great for startup, fan-in, and tests.

Practice Tasks:

• Write a program that starts 5 tasks and waits for all 5 before printing a summary.
• Add one task that throws an exception and make sure the latch still releases.
• Replace the latch with CyclicBarrier and compare the behavior.