CyclicBarrier.

Hook: Think of CyclicBarrier like a group photo line: nobody leaves until every person has arrived, and then the line resets for the next picture.

Question: What is CyclicBarrier in Java?

Answer: CyclicBarrier is a synchronization aid for a fixed number of threads that must all reach the same checkpoint before any of them can continue. Each thread calls await(); when the last one arrives, everyone is released together, and an optional barrier action runs once. It is reusable, so after one round finishes, the same barrier can be used again.

Interview-Ready Answer: In Java, CyclicBarrier lets a fixed number of threads wait for each other at a rendezvous point. I call await() from each thread, and when the last thread arrives, all threads are released together; I can also provide a barrier action that runs once per cycle. The key detail is that it is reusable, and if one thread is interrupted, times out, or the action fails, the barrier becomes broken and waiting threads get BrokenBarrierException.

What it is

CyclicBarrier lives in java.util.concurrent and is used when a group of worker threads must move through a problem in phases. The word cyclic means it can be used again and again, unlike one-shot tools. The word barrier means nobody crosses until the whole group has arrived.

How it works under the hood

1. You create the barrier with a fixed number of parties (the threads that must arrive). There is no default party count; you must choose it up front.
2. Each thread does its independent work first, then calls await() at the checkpoint.
3. The barrier tracks how many parties are still missing in the current round. Conceptually, this is a countdown for the current generation (a cycle of the barrier).
4. If the thread is not the last one, it blocks and waits. In the JDK implementation, this waiting is done with a lock and condition, so the thread sleeps instead of busy-waiting.
5. When the last thread arrives, it becomes the releaser. If a barrier action was supplied, that action runs once in that last arriving thread before the others are released.
6. After the action finishes, the barrier resets itself for the next generation, and all waiting threads wake up and continue.
7. If any thread is interrupted, times out, or the barrier action throws an exception, the barrier becomes broken. All waiting threads are woken up and get BrokenBarrierException, and future calls to await() will also fail until you call reset().

When and why to use it

Use CyclicBarrier when the work is naturally split into phases and every worker must finish a phase before the next phase starts. Good examples are parallel image processing, simulation steps, batch analytics, and game rounds. It is a great fit when the number of workers is known and fixed, such as 4 CPU-bound tasks coordinated by a thread pool.

Do not use it for open-ended producer-consumer pipelines or situations where threads join and leave dynamically. In those cases, a different tool is a better match.

Performance and complexity notes

The coordination work is effectively O(1) per arriving thread: one arrival, one count update, one possible wake-up. The barrier state itself is small and fixed, while the real cost is that threads may block and hold onto their stack and scheduling slot. In practice, barriers are common in small pools like 4, 8, 16, or 32 worker threads, and barrier actions should be short because they run on the critical path for the whole group.

Important details interviewers like: await() can return an arrival index, where the last thread gets 0 and earlier arrivals get larger numbers. Also, the barrier has no fairness guarantee about which waiting thread resumes first. Since Java 5, the API has been stable; the main behavior you must remember is the broken state and the fact that the barrier can be reused after a clean trip or after a reset.

Edge cases to remember

• If one party never arrives, everyone else can wait forever unless you use the timed await(long, TimeUnit) form.
• If one thread times out or is interrupted, the whole barrier breaks, not just that thread.
• reset() does not wait politely for the current round to finish; it breaks the current generation and starts a new one.
• The barrier action should never do heavy work or long blocking I/O, because that delays the release of every waiting thread.

Real-world story

Imagine a checkout service that runs three independent checks in parallel: inventory availability, fraud scoring, and shipping eligibility. Each worker thread finishes its own task, then all three meet at a CyclicBarrier before the service decides whether the order can be placed. The barrier action can combine the partial results into one final decision.

What goes wrong when people misunderstand it? A team once assumed the barrier would quietly wait forever. One fraud-scoring call started taking 5 seconds, while the other workers used a 2-second timeout. Two threads timed out, the barrier became broken, and the third thread arrived later to find BrokenBarrierException. In production, this showed up as spikes in checkout latency, error logs full of broken-barrier messages, and users seeing spinning loaders followed by failed orders. The fix was to add sensible timeouts, monitor slow upstream calls, and keep the barrier action tiny.

Follow-up & Tricky Questions:

• What does await() return? It returns the arrival index for that thread. The last thread to arrive gets 0, and earlier threads get larger numbers, which can be useful for choosing one thread to do extra work.
• Can a CyclicBarrier be reused? Yes. That is the main difference from CountDownLatch: after a successful trip, the barrier resets automatically for the next cycle.
• What happens if one thread is interrupted? The barrier breaks, the interrupted thread gets InterruptedException, and the other waiting threads get BrokenBarrierException.
• What is the barrier action for? It is a small piece of code that runs once when the last thread arrives, usually to merge results or update shared state before everyone continues.
• When should I choose Phaser instead? Choose Phaser when parties can register or deregister dynamically. CyclicBarrier is simpler, but only for a fixed number of participants.
• Tricky: If the barrier breaks, can waiting threads still pass? No. They are released with failure, not with success, and the barrier stays broken until it is reset.
• Tricky: Does reset() wait for the current round to finish? No. It immediately breaks the current generation, so use it carefully in live code.
• Tricky: Is the barrier action run by a special thread? No. It runs in the last arriving thread, which is why that action must be short and safe.

Common Mistakes:

• Using it for a one-shot task. Correction: if you only need a single countdown, CountDownLatch is usually the simpler choice.
• Forgetting that the party count is fixed. Correction: if threads may join or leave, use Phaser instead.
• Putting heavy work in the barrier action. Correction: keep the action short because it blocks release for everyone.
• Assuming one timeout only hurts one thread. Correction: a timeout breaks the whole barrier for the current generation.

Memory Hook: Picture three hikers at a mountain checkpoint. Nobody moves to the next trail until all hikers arrive, and then the checkpoint opens again for the next leg of the journey.

Cheat Sheet:

• Fixed number of threads meet at a checkpoint.
• await() blocks until all parties arrive.
• The last arrival can run a barrier action.
• The barrier is reusable after each cycle.
• Interrupt, timeout, or action failure breaks the barrier.
• Use Phaser if party count changes.

Practice Tasks:

• Write a 4-thread demo where each thread prints its arrival index.
• Change the example to use await(1, TimeUnit.SECONDS) and observe the broken barrier path.
• Replace the barrier action with a small aggregation step, such as summing partial values from worker threads.