Producer–Consumer

Three parts, and only one of them is shared

• Producer — runs its own loop: make an item, put() it in the buffer, repeat. It never calls the consumer and does not know how many consumers exist.
• Consumer — runs its own loop: take() an item from the buffer, process it, repeat. It never calls the producer and does not know how many producers exist.
• Bounded buffer — the only shared state, and therefore the only thing that needs locking. It holds a queue of items and a maximum capacity. Every rule about safety lives inside this one object.

That last point is what makes the pattern so valuable in an interview answer: it takes a messy N-threads-touching-N-things problem and shrinks all the synchronisation into one class. Get the buffer right and both sides can be plain sequential code.

The two blocking rules

A bounded buffer has a fixed capacity, so both operations have a condition they must wait on. put() cannot add to a full buffer, and take() cannot remove from an empty one. Instead of failing or spinning in a busy loop burning CPU, the calling thread goes to sleep and is woken when the situation changes. A monitor — a lock plus one or more wait-sets attached to it — is the primitive that lets a thread release the lock and sleep atomically.

// The whole pattern, in one class. Everything shared lives here.
class BoundedBuffer<T> {
    private final Queue<T> q = new ArrayDeque<>();
    private final int capacity;                     // the BOUND

    public synchronized void put(T item) throws InterruptedException {
        while (q.size() == capacity) {              // while, NOT if
            wait();                                 // release lock + sleep
        }
        q.add(item);
        notifyAll();                                // "buffer is no longer empty"
    }

    public synchronized T take() throws InterruptedException {
        while (q.isEmpty()) {                       // while, NOT if
            wait();                                 // release lock + sleep
        }
        T item = q.remove();
        notifyAll();                                // "buffer is no longer full"
        return item;
    }
}

Read the shape rather than the syntax: check the condition, sleep while it holds, do the work, then wake everyone. Every hand-rolled Producer–Consumer in every language is this, whatever the local names are — wait()/notifyAll() in Java, await()/signal_all() on a Condition in Python, cv.wait(lock, pred)/notify_all() in C++.

Why notifyAll() beats notify() here

In the simple design above, producers and consumers wait on the same monitor, so the wait-set contains a mix of both. notify() wakes exactly one arbitrary waiter — and it might wake a producer when what you needed was to release a consumer. That producer re-checks its while (full) condition, sees it still holds, and goes straight back to sleep, having consumed the only wakeup. Now nobody is running and nobody will be signalled again: a lost wakeup, and your program deadlocks with work still queued. notifyAll() wakes everybody, they all re-check, the wrong ones sleep again, and the right one proceeds. Slightly wasteful, always correct. The efficient alternative is not notify() — it is giving each side its own condition variable (notFull and notEmpty) so you can signal precisely the group you mean, which is exactly what ReentrantLock with two Condition objects gives you.

Why the buffer must be bounded

An unbounded queue looks friendlier — the producer never blocks, so nothing ever stalls. That is exactly the trap. If your producer is on average faster than your consumer, the queue length grows without limit, and the only thing that eventually stops it is an OutOfMemoryError or the OOM killer. Worse, latency quietly rots long before that: an item sitting behind a million others might be minutes old by the time it is processed. The bound is a feature, not a limitation. A full buffer pushes the pain backwards to the producer — that is what back-pressure means — so the system slows down honestly instead of failing catastrophically. In the prototype, the ∞ unbounded chip shows it: items spill past the box in red and nothing ever waits.

Many producers, many consumers

Nothing above assumes there is only one of each. Because all the coordination lives inside the buffer, you can run 8 producers and 3 consumers with zero code changes — that is the real reason this pattern scales. Each take() hands an item to exactly one consumer (they compete for items, they do not each get a copy — that would be publish/subscribe instead). Adding consumers is how you make a slow stage keep up; the queue length is your live signal for whether you need more.

Just use a BlockingQueue

You should be able to write the class above in an interview, and you should almost never write it in production. Every platform ships a battle-tested version: ArrayBlockingQueue/LinkedBlockingQueue in Java, queue.Queue(maxsize=...) in Python, a buffered channel make(chan T, 5) in Go, BlockingCollection<T> in C#. They handle fairness, timeouts, bulk drains and interruption — details that are easy to get subtly wrong by hand. Use Executors.newFixedThreadPool(n) and you get the whole pattern (bounded queue plus consumer threads) in a single line.

Reach for Producer–Consumer when...

• The two sides run at different speeds and you want the fast one to keep going instead of waiting for each slow call — a request handler that hands work off, a scraper feeding a parser.
• Work arrives in bursts but must be processed at a steady rate. The buffer absorbs the spike; the bound stops the spike from becoming an outage.
• You want to scale one stage independently — add consumers to drain a queue faster, without touching a line of producer code.
• A resource must be used by one thread at a time — a single printer, a single log file, one database connection. Funnel all work through a queue and let one consumer own the resource.

Skip it when...

• The caller needs the result right now. A queue is inherently asynchronous. If you need the answer to continue, just call the function — or use a future/promise on top.
• The work is trivially fast. Locking a queue and waking a thread can cost more than the work itself. Measure before you add a hop.
• Every consumer needs every item. That is publish/subscribe, not Producer–Consumer — here each item goes to exactly one consumer.
• Strict global ordering across many consumers matters. One queue with N consumers gives you FIFO dequeue order but concurrent, out-of-order completion. Use one consumer, or partition by key.