Java Concurrency Interview

Synchronizers: latches, barriers, semaphores question 47 of 180 junior

What does a Semaphore actually protect?

A lock answers "one at a time". A semaphore answers "at most N at a time", which is what you want when the constraint lives outside your process: a downstream service that tolerates 50 concurrent calls, a pool of 20 connections, a licence for 4 decoders.

Semaphore permits = new Semaphore(50);
permits.acquire();
try {
    callDownstream();
} finally {
    permits.release();
}

Two things interviewers probe. A binary semaphore (new Semaphore(1)) is not a lock: it has no owner, so any thread can release it, and it is not reentrant, so the same thread acquiring twice deadlocks. That ownerless property is occasionally exactly what you want, when one thread signals and another proceeds. And permits are just a count: releasing more than you acquired silently inflates the limit, which is a bug that surfaces as an overloaded dependency weeks later.

synchronizers semaphore

Quiz yourself on Synchronizers: latches, barriers, semaphores Suggest a correction