Understanding Java CyclicBarrier: Usage, Implementation Details, and Comparison with CountDownLatch

After introducing CountDownLatch in a previous article, the author points out that CountDownLatch is a one‑time counter and therefore unsuitable for scenarios that require repeated synchronization, such as multiple rounds of a game; the article then introduces CyclicBarrier as a reusable barrier.

CyclicBarrier (literally “cyclic barrier”) provides a reusable synchronization point where a group of threads wait until a predefined number of parties have arrived, after which all waiting threads are released and the barrier can be used again.

The author uses a bus‑loading analogy: a bus departs only when it is full, illustrating how CyclicBarrier fits scenarios where a group must wait until enough participants are present before proceeding.

A side‑by‑side comparison shows that CountDownLatch works like a game loading screen—threads wait for a single event—whereas CyclicBarrier works like a driver waiting for all seats to be filled before the trip starts, emphasizing its repeatable nature.

import java.util.Date; import java.util.Random; import java.util.concurrent.*; public class CyclicBarrierExample { public static void main(String[] args) { final CyclicBarrier cyclicBarrier = new CyclicBarrier(2, new Runnable() { @Override public void run() { System.out.println("People are full, ready to depart: " + new Date()); } }); Runnable runnable = new Runnable() { @Override public void run() { int randomNumber = new Random().nextInt(3) + 1; System.out.println(String.format("I am %s, %d seconds to station, now: %s", Thread.currentThread().getName(), randomNumber, new Date())); try { TimeUnit.SECONDS.sleep(randomNumber); cyclicBarrier.await(); System.out.println(String.format("Thread %s boarded, time: %s", Thread.currentThread().getName(), new Date())); } catch (InterruptedException e) { e.printStackTrace(); } catch (BrokenBarrierException e) { e.printStackTrace(); } } }; ExecutorService threadPool = Executors.newFixedThreadPool(10); threadPool.submit(runnable); threadPool.submit(runnable); threadPool.submit(runnable); threadPool.submit(runnable); threadPool.shutdown(); } }

The execution result demonstrates that when the barrier count is set to 2, the first two threads reach the barrier and trigger the barrier action, then after a short delay the next two threads reach the barrier and trigger the action again, showing the reusable nature of CyclicBarrier.

Internally, CyclicBarrier is built on a ReentrantLock (which itself relies on AQS). It maintains an internal counter that decrements each time a thread calls await() . When the counter reaches zero, all waiting threads are released and the counter is reset to the original parties value for the next round.

Key methods include:

CyclicBarrier(int parties) : creates a barrier for the given number of parties.

CyclicBarrier(int parties, Runnable barrierAction) : also specifies an action to run when the barrier is tripped.

getParties() : returns the number of parties required to trip the barrier.

getNumberWaiting() : returns the number of threads currently waiting.

await() and await(long timeout, TimeUnit unit) : block until the barrier is tripped or an exception occurs (InterruptedException, BrokenBarrierException, TimeoutException).

isBroken() : indicates whether the barrier is in a broken state.

reset() : returns the barrier to its initial state, releasing waiting threads with a BrokenBarrierException and clearing the broken flag.

In summary, CyclicBarrier uses a ReentrantLock to ensure atomic updates of its counter, and its primary advantage over CountDownLatch is the ability to be reused across multiple synchronization cycles, making it a valuable tool for complex multithreaded coordination.