Semaphore.

Hook: Interviewers love semaphores because they test whether you can control crowding in a system, not just protect data.

Question: What is a semaphore in Java?

Answer: A semaphore is a counter of permits. A thread calls acquire() to take a permit and release() to give one back; if no permits are available, the thread blocks or can fail fast with tryAcquire(). In Java, Semaphore is in java.util.concurrent and is used to limit how many threads can enter a section at the same time.

Interview-Ready Answer: I use a semaphore when I want to limit concurrency, not just protect a single critical section. It gives me a fixed number of permits, so only that many threads can proceed at once, and the rest wait. In Java, I’d use Semaphore for things like capping access to a database pool or an external API, and I’d always release permits in a finally block to avoid leaks.

What a semaphore really is

Detailed Explanation: Think of a semaphore as a box of tickets. Each ticket is a permit—a simple allowed entry token. If the box has 5 tickets, at most 5 threads can hold one at a time. A binary semaphore has 1 permit and behaves a bit like a lock, while a counting semaphore has many permits and is more flexible.

How it works under the hood

1. You create it with an initial permit count, for example new Semaphore(3).
2. A thread calls acquire(). If a permit exists, the count is decremented immediately and the thread continues.
3. If no permit exists, the thread is placed into a waiting queue and parked (paused by the JVM until it can resume).
4. Another thread calls release(). The permit count increases, and one waiting thread may be unparked and allowed to continue.
5. If you use new Semaphore(permits, true), Java tries to hand permits out in FIFO order; with the default unfair mode, a newly arriving thread may sometimes grab a permit sooner and get better throughput.

One important advanced detail: semaphore operations provide the memory visibility you expect in concurrency. In practice, actions done before release() become visible to a thread after it successfully acquire()s that permit.

When to use it

• Limit concurrency: keep only 10–50 calls in flight to an external API.
• Protect a scarce pool: model a fixed number of database connections, file handles, or GPU workers.
• Gate a resource: allow only a few uploads, jobs, or batch tasks to run together.

Semaphore vs. other concurrency tools

A lock is for “only one thread at a time,” while a semaphore is for “up to N at a time.” A CountDownLatch is for waiting until some work finishes, not for limiting access. Also, a semaphore is not owned by the thread that acquired it, so another thread can release it—useful, but also easy to misuse.

Performance and practical numbers

• The logical cost of acquire() and release() is O(1) for the permit counter.
• If threads block, the real cost includes parking, unparking, and context switches, which are much slower than plain CPU work.
• Fair semaphores reduce starvation risk, but they usually lower throughput because they enforce queue order more strictly.
• Real systems often use small numbers like 5, 10, 20, or 100 permits depending on backend capacity; for example, a payment gateway might safely allow 20 concurrent requests per instance.

Important gotchas

• Always release in finally; otherwise a thrown exception can leak a permit and gradually freeze the system.
• Over-releasing is possible because Java does not bind permits to thread ownership; that can silently inflate concurrency.
• availablePermits() is only a snapshot, not a guarantee for future safety.
• tryAcquire() with a timeout is useful for fail-fast behavior when waiting is worse than dropping or retrying.

Memory mental model: “A semaphore is a parking lot with N spots: if all spots are full, cars wait outside; when a car leaves, one waiting car can enter.”

Real-World Example: Imagine a checkout service in an e-commerce app that calls a payment provider. The provider only handles a small number of concurrent requests well, so each app instance uses a semaphore with 20 permits. That keeps traffic smooth: at most 20 payment calls run at once, and the rest wait briefly instead of overwhelming the gateway.

What goes wrong when people misunderstand it? A developer puts release() outside a finally block. One exception path skips the release, permits slowly leak, and after enough failures every request blocks on acquire(). In production, you see thread pools stuck, rising queue time, and logs like “waiting for payment slot” while users see endless spinners or checkout timeouts. If someone over-releases instead, the app may flood the gateway and trigger 429 rate-limit errors.

Follow-up & Tricky Questions:

• How is a semaphore different from a lock? A lock gives exclusive ownership to one thread; a semaphore gives a fixed number of permits and does not track thread ownership.
• What does the fairness flag do? new Semaphore(permits, true) tries to serve waiting threads in arrival order, which reduces starvation but can reduce throughput.
• What happens if a thread is interrupted while waiting? acquire() throws InterruptedException, so the code should stop waiting, restore the interrupt flag if appropriate, and not assume a permit was obtained.
• Can a different thread call release()? Yes. That is legal for semaphores, unlike locks, because permits are not owned by a specific thread.
• Why would you choose tryAcquire(timeout)? When waiting too long is worse than failing fast, such as a UI request or a bounded API call budget.
• Can you use a semaphore as a mutex? Yes, a binary semaphore can behave like one, but a real lock is usually clearer for mutual exclusion.
• Gotcha: if availablePermits() is 1, can I safely proceed? No, because another thread can take that permit immediately after your check; you must acquire atomically.
• Gotcha: does a semaphore automatically protect shared data? Not by itself. It only controls access; you still need correct synchronization for the data you are protecting.

Common Mistakes:

• Forgetting finally: This leaks permits. Fix: release in a finally block even when exceptions happen.
• Using a semaphore when you really want a lock: A semaphore does not guarantee single-thread ownership. Fix: use Lock or synchronized for mutual exclusion.
• Assuming fairness by default: The default constructor is not fair. Fix: pass true only when FIFO-like behavior matters enough to accept lower throughput.
• Checking first, then acting later: That race is unsafe. Fix: make the permit decision atomic with acquire() or tryAcquire().

Memory Hook: “Semaphore = parking lot tickets.” If you have a ticket, you park; if not, you wait outside until someone leaves.

Cheat Sheet:

• Semaphore = permit counter for limiting concurrency.
• acquire() blocks, tryAcquire() can fail fast, release() returns a permit.
• Binary semaphore = 1 permit; counting semaphore = many permits.
• Fair semaphore = more orderly, usually slower.
• Always release in finally.
• Use it to cap access to scarce resources, not to “protect” data by itself.

Practice Tasks:

• Change the demo from 3 permits to 1 permit and observe how it behaves like a lock.
• Replace acquire() with tryAcquire(100, TimeUnit.MILLISECONDS) and see how the failure path changes.
• Add a second semaphore to model two different limited resources, such as API calls and database connections.