The producer–consumer problem

For this lesson, we'll build the solution four ways, from the version you'd write on a whiteboard to the one you'd ship. We'll write a real bounded blocking queue with synchronized and wait/notifyAll, upgrade it to ReentrantLock with two Conditions, swap it for BlockingQueue in production, and then deal with the parts tutorials skip: how to stop consumers cleanly, why the queue must be bounded, and how big to make it. Interviewers love this one because "implement a bounded blocking queue" fits in 10 minutes of code and hides about five classic concurrency bugs.

01Picture it first: the pass shelf

Picture a busy restaurant kitchen. Cooks plate dishes and put them on the pass, the shelf between the kitchen and the dining room. Waiters pick dishes up and carry them out. The shelf holds five plates.

Two awkward moments keep happening. When all five slots are full, a cook holding a hot plate has nowhere to put it, so they wait. When the shelf is empty, a waiter has nothing to carry, so they wait. And the moment a waiter takes a plate, a waiting cook should hear "there's space now", and vice versa.

Translate it to Java and nothing changes. Cooks are producer threads, waiters are consumer threads, and the shelf is a bounded buffer, a queue with a fixed capacity. You'll find this shape everywhere:

• Thread pools: your code produces tasks with submit(), worker threads consume them from a work queue.
• Async logging: request threads drop log events in a queue; one background thread writes them to disk.
• Pipelines: parse, then enrich, then save, with a queue between each stage.
• Backpressure: when the buffer is full, the producer is slowed down instead of the system drowning. That slow-down is a feature, and we'll come back to it.

02What a correct solution must do

Before any code, here are the four rules. Every bug in this lesson breaks one of them.

1. Mutual exclusion. Only one thread at a time may touch the buffer's fields. Two cooks putting into the same slot lose a dish.
2. Wait when full. A producer that finds no space must block, not spin and not overwrite.
3. Wait when empty. A consumer that finds nothing must block, not spin and not return garbage.
4. Wake the right side. After a put, a sleeping consumer must eventually wake. After a take, a sleeping producer must. Miss this and everyone sleeps forever.

03Solution 1: synchronized, wait and notifyAll

First, the buffer itself. We don't want to shift array elements on every take, so we use a circular buffer: a plain array plus two indexes that chase each other round and round. tail is where the next put goes, head is where the next take comes from, and count says how many items are in there.

Here's the version I'd write on a whiteboard, wrapped in a test: 2 cooks make 10,000 numbered dishes each, 2 waiters take them, and at the end we check that every dish was served exactly once using a checksum (the sum of 1 to 20,000 is 200,010,000).

public class PassShelf {

    // A bounded blocking queue: one lock, one wait set, a circular array.
    static final class BoundedBuffer<T> {
        private final Object[] items;
        private int head;    // next slot to take from
        private int tail;    // next slot to put into
        private int count;   // how many items are on the shelf

        BoundedBuffer(int capacity) {
            items = new Object[capacity];
        }

        public synchronized void put(T item) throws InterruptedException {
            while (count == items.length) {     // full: wait for space
                wait();
            }
            items[tail] = item;
            tail = (tail + 1) % items.length;
            count++;
            notifyAll();                        // wake anyone waiting for an item
        }

        @SuppressWarnings("unchecked")
        public synchronized T take() throws InterruptedException {
            while (count == 0) {                // empty: wait for an item
                wait();
            }
            T item = (T) items[head];
            items[head] = null;                 // let the GC have it
            head = (head + 1) % items.length;
            count--;
            notifyAll();                        // wake anyone waiting for space
            return item;
        }
    }

    static final int PER_COOK = 10_000;
    static final Integer STOP = -1;             // poison pill

    public static void main(String[] args) throws InterruptedException {
        BoundedBuffer<Integer> shelf = new BoundedBuffer<>(5);
        long[] served = new long[2], sums = new long[2];
        Thread[] cooks = new Thread[2], waiters = new Thread[2];
        for (int i = 0; i < 2; i++) {
            int base = i * PER_COOK, me = i;    // cook 0 makes 1..10000, cook 1 makes 10001..20000
            cooks[i] = new Thread(() -> {
                try {
                    for (int d = 1; d <= PER_COOK; d++) shelf.put(base + d);
                } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
            });
            waiters[i] = new Thread(() -> {
                try {
                    for (Integer dish; !(dish = shelf.take()).equals(STOP); ) {
                        served[me]++;
                        sums[me] += dish;
                    }
                } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
            });
        }
        for (int i = 0; i < 2; i++) { cooks[i].start(); waiters[i].start(); }
        for (Thread t : cooks) t.join();
        for (Thread t : waiters) shelf.put(STOP);   // one pill per waiter
        for (Thread t : waiters) t.join();

        long n = 2L * PER_COOK;
        System.out.printf("waiter-0 served %,d dishes, waiter-1 served %,d%n", served[0], served[1]);
        System.out.printf("total served = %,d (expected %,d)%n", served[0] + served[1], n);
        System.out.printf("checksum     = %,d (expected %,d)%n", sums[0] + sums[1], n * (n + 1) / 2);
    }
}

Two real runs of java PassShelf.java on my laptop (JDK 21 and 26 behave the same). The split between waiters changes every run; the totals never do:

waiter-0 served 10,471 dishes, waiter-1 served 9,529
total served = 20,000 (expected 20,000)
checksum     = 200,010,000 (expected 200,010,000)

waiter-0 served 6,978 dishes, waiter-1 served 13,022
total served = 20,000 (expected 20,000)
checksum     = 200,010,000 (expected 200,010,000)

Notice four things:

1. while, never if. A thread can wake up and find the condition false again: another consumer grabbed the dish first, or it was a spurious wake-up. The loop re-checks before acting.
2. Both methods are synchronized on the same object. That gives rule 1 (one thread in the buffer at a time), and it's also required: calling wait() without holding the lock throws IllegalMonitorStateException.
3. wait() releases the lock while sleeping. That's how a cook can sleep "inside" put and still let a waiter into take.
4. The checksum proves exactly-once. A lost dish or a dish served twice would change the sum. Matching counts alone wouldn't catch a duplicate plus a loss.

04Why notifyAll and not notify?

Here's the bit that trips people up. A Java object has one wait set, one bench where every waiting thread sits. In our buffer that bench holds two kinds of thread waiting for two different things: cooks waiting for "not full" and waiters waiting for "not empty".

notify() wakes one arbitrary thread from that bench. Picture a waiter that just took a dish and calls notify(), meaning to wake a cook. The JVM picks... another waiter. That waiter checks, finds the shelf still empty, and goes back to sleep without notifying anyone. The cooks never hear about the free slot. With the right timing, every thread ends up asleep, and the program hangs with no exception and no CPU use.

notifyAll() wakes everybody, so whoever can make progress will. It's correct, but it has a cost called the thundering herd: with 50 threads on the bench, one put wakes all 50, they queue for the lock one by one, and 49 of them re-check and sleep again.

05Solution 2: ReentrantLock with two Conditions

The fix is to give each kind of waiter its own room. A ReentrantLock can hand out any number of Condition objects, each with its own wait set. Cooks await() on notFull, waiters await() on notEmpty, and now signal() (the notify() of conditions) is safe, because everyone in a room is waiting for the same thing.

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

final class BoundedBuffer<T> {
    private final Object[] items;
    private int head, tail, count;
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull = lock.newCondition();   // cooks wait here
    private final Condition notEmpty = lock.newCondition();  // waiters wait here

    BoundedBuffer(int capacity) {
        items = new Object[capacity];
    }

    public void put(T item) throws InterruptedException {
        lock.lockInterruptibly();
        try {
            while (count == items.length) notFull.await();
            items[tail] = item;
            tail = (tail + 1) % items.length;
            count++;
            notEmpty.signal();              // one waiter, from the right room
        } finally {
            lock.unlock();
        }
    }

    @SuppressWarnings("unchecked")
    public T take() throws InterruptedException {
        lock.lockInterruptibly();
        try {
            while (count == 0) notEmpty.await();
            T item = (T) items[head];
            items[head] = null;
            head = (head + 1) % items.length;
            count--;
            notFull.signal();               // one cook, from the right room
            return item;
        } finally {
            lock.unlock();
        }
    }
}

I ran the same exactly-once harness with 4 cooks and 4 waiters against this version:

4 cooks, 4 waiters: checksum 800,020,000 (expected 800,020,000)

This isn't a toy. Open ArrayBlockingQueue.java in OpenJDK and you'll find this exact design: one final ReentrantLock lock, two conditions named notEmpty and notFull, a circular items array with takeIndex, putIndex and count, and put looping on notFull.await(). Notice the unlock() in finally: unlike synchronized, a ReentrantLock isn't released for you if an exception escapes. We cover the lock itself properly in the "ReentrantLock and Condition" lesson.

06Solution 3: the production answer is BlockingQueue

You should be able to write Solutions 1 and 2. You should almost never ship them. java.util.concurrent.BlockingQueue is the producer-consumer buffer, already tested by millions of services. The three you'll meet most:

The API has three flavours of each operation, and choosing the right one is half the design:

And here's the thing many people miss: you use a producer-consumer queue every time you call executor.submit(task). A ThreadPoolExecutor is a BlockingQueue<Runnable> plus N worker threads in a take() loop. Your code is the producer.