What does the fairness flag on a Semaphore control, and what is the tradeoff?

## What "fairness" means here When several threads are **blocked** in `acquire()` waiting for a permit, and a permit becomes available (someone calls `release()`), *which* waiting thread gets it? That ordering policy is what the **fairness flag** controls. ```java new Semaphore(5); // non-fair (default) new Semaphore(5, true); // fair ``` ## Fair (true): FIFO, no overtaking Waiting threads sit in a first-in-first-out queue (the `AbstractQueuedSynchronizer` wait queue that `Semaphore` is built on). A fair semaphore grants the next permit to the **longest-waiting** thread. Critically, a brand-new thread calling `acquire()` will **not** snatch a permit if others are already queued — it goes to the back of the line. This guarantees **no starvation**: every waiter is eventually served in order, so wait times are bounded and predictable. ## Non-fair (false, the default): barging allowed A non-fair semaphore permits **barging**. When a permit is released, a thread that happens to call `acquire()` at that very moment can grab the permit **immediately**, even though other threads have been waiting longer. The newcomer "jumps the queue." Why is this the default? **Throughput.** Handing a permit to a queued thread requires waking it up — a context switch and scheduling delay. If a running thread can take the permit right now without that handoff, the CPU does useful work sooner. Under heavy contention, barging measurably increases throughput because it avoids a stream of wake-up/handoff round-trips. ## The tradeoff in one line - **Fair** → predictable, no starvation, lower throughput. - **Non-fair** → higher throughput, but a thread can **starve** (wait indefinitely / suffer terrible tail latency) if it keeps getting barged past. **Starvation** = a thread is perpetually denied progress because others keep being chosen ahead of it. Fairness is the standard cure. ## A subtle exception: tryAcquire() ignores fairness The untimed, no-argument `tryAcquire()` **always barges**, *even on a fair semaphore*. It checks for a free permit and takes it without consulting the wait queue. So if you rely on fairness for ordering, be aware that `tryAcquire()` callers can still cut the line. The **timed** `tryAcquire(timeout, unit)`, by contrast, queues and honours fairness. ## How to choose | Situation | Pick | |---|---| | Latency SLA / bounded wait per request | fair | | Fairness across many clients/tenants | fair | | Maximise throughput, occasional long waits OK | non-fair (default) | | Low/no contention (rarely any waiters) | non-fair — fairness barely matters | When contention is low, the choice is almost irrelevant (there's rarely a queue to overtake). The decision matters under **sustained contention**, where barging's throughput win and starvation risk both become real. ## Cost of fairness Fairness isn't free at the mechanism level either: a fair acquire must check the queue and often park even when a permit is technically available, adding overhead. Benchmarks generally show non-fair outperforming fair under contention — which is precisely why `Semaphore`, `ReentrantLock`, etc. all default to non-fair.