Producer-Consumer with wait() and notifyAll() — No BlockingQueue

“How do you implement a producer-consumer queue with wait() and notifyAll() (not BlockingQueue)?”

This is the standard guarded-block pattern applied to a bounded buffer: producers block while it's full, consumers block while it's empty, and every state change (a successful add or remove) wakes up threads that might now be able to proceed.

class BoundedBuffer<T> {
    private final Queue<T> queue = new LinkedList<>();
    private final int capacity;
    BoundedBuffer(int capacity) { this.capacity = capacity; }

    synchronized void put(T item) throws InterruptedException {
        while (queue.size() == capacity) {
            wait(); // releases the lock, blocks until notified
        }
        queue.add(item);
        notifyAll(); // wake any consumer(s) waiting on "not empty"
    }

    synchronized T take() throws InterruptedException {
        while (queue.isEmpty()) {
            wait();
        }
        T item = queue.remove();
        notifyAll(); // wake any producer(s) waiting on "not full"
        return item;
    }
}

Producer blocks when

queue.size() == capacity

Consumer blocks when

queue.isEmpty()

After put/take

notifyAll() wakes threads waiting on the OTHER condition

Why while, not if

spurious wakeups + multiple waiters — must re-check after waking

notifyAll() (not notify()) matters here specifically because producers and consumers share the same monitor. notify() wakes one arbitrary waiting thread, which might be another producer that still can't proceed instead of the consumer that just became unblocked. notifyAll() wakes everyone; each re-checks its own while condition, and only the ones that can actually proceed continue — the rest go straight back to waiting.

Why wait() requires the lock, mechanically: wait() is defined to atomically release the monitor and suspend the thread — it has to hold the lock in order to give it up as part of that atomic step, otherwise there'd be a race between "about to wait" and "actually waiting" where a notify() from another thread could slip through and be missed entirely. That's also why notify()/notifyAll() require the lock too, and why calling any of the three outside a synchronized block on that same monitor throws IllegalMonitorStateException — the JVM refuses to run code whose correctness depends on a lock it never proves you're holding.

Spurious wakeups are the JVM/OS being explicitly allowed to wake a waiting thread with no corresponding notify() at all — permitted by the Java spec (and inherited from the underlying OS thread APIs) as an implementation looseness, not a bug to work around defensively "just in case." It's a real, documented possibility, which is exactly why the guard has to be a while loop re-checking the actual condition, rather than an if that trusts a wakeup to mean the condition is now true. An if would let a spuriously-woken producer or consumer barrel ahead on a buffer that's still full or still empty.

ArrayBlockingQueue and LinkedBlockingQueue implement essentially this pattern internally — production code uses a Condition per direction instead of raw wait/notify for efficiency, but the logic is the same guarded-block shape. Building this by hand once is what lets you actually reason about BlockingQueue's behavior instead of treating it as a black box.

Keywords they're listening for:

• ✓ wait() releases the lock and blocks; must be called inside synchronized
• ✓ always re-check the condition in a while loop, never an if
• ✓ notifyAll() over notify() when multiple different conditions share one monitor
• ✓ this is the mechanism BlockingQueue implements internally

• ✗Using if instead of while around wait() — misses spurious wakeups and skips the re-check
• ✗Calling wait()/notify() outside a synchronized block (throws IllegalMonitorStateException)
• ✗Using notify() when multiple different wait conditions share one monitor

• ✓Always loop on the condition with while, never if
• ✓Use notifyAll() unless you can prove only one type of waiter exists on the monitor
• ✓Reach for java.util.concurrent's BlockingQueue in real production code — build this by hand mainly to internalize the mechanism

1. 1Why must wait() be called inside a synchronized block?
2. 2What's a spurious wakeup, and why does that alone require a while loop?
3. 3How does this relate to ArrayBlockingQueue's actual implementation?
4. 4When, if ever, is notify() safe to use instead of notifyAll()?

• wait/notify
• synchronized
• ArrayBlockingQueue
• guarded blocks