Concurrency Utilities (Locks & Synchronizers)

A Semaphore holds a set number of permits. A thread calls acquire() to take a permit (waiting if none are free) and release() to give it back. It limits how many threads can use a resource at once.

A CyclicBarrier is a reusable meeting point for a fixed number of threads. Each thread calls await() and blocks until all of them arrive. Then they all proceed, and the barrier resets so it can be used again for the next round.

A ReadWriteLock has two locks: a read lock many threads can hold at once, and a write lock only one thread can hold (with no readers at the same time). Use it when data is read far more often than written, so reads don't block each other.

tryLock() tries to grab the lock and returns true or false right away instead of waiting. tryLock(time, unit) waits only up to a time limit. This lets a thread give up instead of blocking forever, so threads can back off and avoid getting stuck in a deadlock.

ReentrantLock is a lock object you control with explicit lock() and unlock() calls. synchronized is a keyword that locks and unlocks automatically. ReentrantLock adds extra abilities like timed and interruptible locking, but you must remember to unlock it yourself in a finally block.

Create a Semaphore with as many permits as the resource allows. Each user acquires a permit before using the resource and releases it in a finally block afterward. That caps the number of simultaneous users at the permit count.

A CountDownLatch is one-shot: any thread counts it down and waiters proceed at zero. A CyclicBarrier is reusable: a fixed set of threads wait for each other, then all go together and it resets. Use a latch for a single start/done signal, a barrier for repeated lockstep rounds.

A Condition is a waiting area tied to a Lock, created with lock.newCondition(). Threads call await() to wait and signal()/signalAll() to wake them — like wait()/notify() but you can have several separate waiting areas per lock, so you can wake exactly the right group of waiters.

acquire() waits until a permit is free. tryAcquire() takes a permit only if one is available right now and returns true; otherwise it returns false immediately without waiting. tryAcquire(timeout) waits up to a limit before giving up.

await() can throw InterruptedException, so handle it and usually re-set the interrupt flag. Prefer the timed await so a dead worker can't hang you forever. For CyclicBarrier also catch BrokenBarrierException, which means another party failed and the barrier is now broken.

Use a Phaser. It is reusable for the multiple stages and lets workers register or deregister between stages, which CountDownLatch (one-shot) and CyclicBarrier (fixed count) cannot do.

A Phaser is a reusable barrier where threads wait for each other at the end of each phase. Unlike CountDownLatch and CyclicBarrier, the number of parties can grow or shrink at runtime, and it supports many phases.

Use synchronized by default — it's simplest. Move to ReentrantReadWriteLock when reads greatly outnumber writes and you want readers to run in parallel. Use StampedLock for very hot, short read paths where you can use optimistic reads, but only if you don't need reentrancy or condition waiting.

Non-reentrant means a thread that already holds the lock cannot acquire it again — if it tries, it blocks waiting for itself and deadlocks. So a method holding the write lock that calls another method which also takes the lock will freeze.

An optimistic read takes no lock at all. You get a 'stamp' (a number), read the data, then call validate(stamp). If no writer changed the data in between, validate returns true and your read was fine; if it returns false, you fall back to a real read lock and read again.

A fair ReentrantLock (new ReentrantLock(true)) hands the lock to waiting threads in the order they asked for it, so no thread is starved. The default unfair lock lets whoever grabs it first win, which is faster overall but can leave some threads waiting longer.

lock() waits for the lock no matter what and ignores interruption while waiting. lockInterruptibly() waits but throws InterruptedException if the thread is interrupted, so the wait can be cancelled. tryLock() doesn't wait at all (or only up to a timeout) and returns true/false.

The fairness flag decides the order waiting threads get permits. Fair (true) serves them first-come-first-served (FIFO), preventing any thread from waiting forever. Non-fair (the default) lets a new thread grab a free permit ahead of those already waiting, which is faster but can starve waiters.

Use a Semaphore when you need to limit how many threads use something at once (N at a time). Use a lock for exclusive access by one thread. Use a CountDownLatch to wait until events finish. Use a BlockingQueue to hand data between threads. A Semaphore only counts permits; it doesn't track owners or carry data.

Exchanger is a meeting point where exactly two threads swap objects. Each thread calls exchange(myValue); both block until the partner arrives, then each receives what the other passed in.

They fall short when the number of participants changes over time or when you want to compose async results without blocking threads. For dynamic, multi-phase coordination use Phaser; for non-blocking result composition use CompletableFuture or structured concurrency.

Each completed round increments the phase number (an int starting at 0). When the phaser terminates, await methods stop blocking and immediately return a negative number, so finishing threads can't deadlock the rest.

StampedLock has three modes: writing (exclusive), reading (shared), and optimistic reading (no lock). Conversion methods like tryConvertToWriteLock take your current stamp and try to switch modes; they return a new stamp on success or 0 on failure, so you must check the result.