Inter-Thread Communication — wait & notify

#Introduction

synchronized stops threads from interfering. Sometimes threads also need to coordinate: a consumer must wait until a producer has put something in a queue; a producer must wait until there's space. Java's built-in mechanism for this is wait(), notify() and notifyAll() — methods of Object, used together with synchronized.

#The Problem: Busy Waiting

// ❌ Busy-waiting: burns a whole CPU core doing nothing useful
while (queue.isEmpty()) {
    // spin
}
Item item = queue.remove();

Sleeping in the loop (Thread.sleep(100)) wastes less CPU but adds latency and is still guesswork. We want a thread to sleep until the condition changes and be woken exactly then.

#wait(), notify() and notifyAll()

Rules:

1. All three must be called while holding obj's monitor — inside synchronized (obj). Otherwise they throw IllegalMonitorStateException.
2. wait() atomically releases the monitor and suspends the thread, so other threads can enter and change the state.
3. A woken thread must re-acquire the monitor before wait() returns — so it doesn't run until the notifier leaves its synchronized block.
4. notify() doesn't release the lock; the lock is released when the notifier exits synchronized.

#The Guarded-Block Pattern

synchronized (lock) {
    while (!condition) {      // ALWAYS a while loop, never an if
        lock.wait();
    }
    // condition is true and we hold the lock — act on it
}

Why while, Not if?

• Spurious wakeups — the JVM is allowed to wake a waiting thread with no notification at all.
• Stolen conditions — with notifyAll(), several consumers wake up; the first one takes the only item, and the others must go back to waiting.
• Wrong notification — producers and consumers share one wait set, so a thread may be woken for a condition it doesn't care about.

Re-checking in a while loop handles all three.

#Producer–Consumer with wait/notify

A bounded buffer — producers block when it's full, consumers block when it's empty:

class BoundedBuffer<T> {

    private final Queue<T> items = new LinkedList<>();
    private final int capacity;

    BoundedBuffer(int capacity) {
        this.capacity = capacity;
    }

    public synchronized void put(T item) throws InterruptedException {
        while (items.size() == capacity) {
            wait();                       // buffer full — wait for space
        }
        items.add(item);
        notifyAll();                      // wake consumers
    }

    public synchronized T take() throws InterruptedException {
        while (items.isEmpty()) {
            wait();                       // buffer empty — wait for an item
        }
        T item = items.remove();
        notifyAll();                      // wake producers
        return item;
    }
}

BoundedBuffer<Integer> buffer = new BoundedBuffer<>(5);

Thread producer = new Thread(() -> {
    try {
        for (int i = 1; i <= 10; i++) {
            buffer.put(i);
            System.out.println("Produced " + i);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}, "producer");

Thread consumer = new Thread(() -> {
    try {
        for (int i = 1; i <= 10; i++) {
            System.out.println("Consumed " + buffer.take());
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}, "consumer");

producer.start();
consumer.start();

Here the methods are synchronized, so the monitor is this, and wait() / notifyAll() are called on this.

#notify() vs notifyAll()

In the buffer above, producers and consumers share one wait set. notify() could wake another producer when the buffer is full, and the consumer would never be woken — a lost wakeup that can hang the program. That's why it uses notifyAll().

#Why Are wait/notify in Object, Not Thread?

Because they're tied to monitors, and every object has a monitor. A thread waits on an object's condition — "this queue is no longer empty" — not on another thread. Any object can be used as a lock, so any object must support waiting and notification.

#The Modern Alternative: BlockingQueue

The same producer–consumer with java.util.concurrent:

BlockingQueue<Integer> queue = new ArrayBlockingQueue<>(5);

// Producer
queue.put(i);            // blocks while full

// Consumer
int item = queue.take(); // blocks while empty

No synchronized, no wait/notify, no lost-wakeup risk — and it supports timeouts (offer(e, timeout), poll(timeout)). Prefer it in real code.

#Key Takeaways

• wait() releases the monitor and suspends the thread until notified; notify()/notifyAll() wake waiters.
• All three must be called while holding the same object's monitor.
• Always wait in a while loop — spurious wakeups and stolen conditions are real.
• notifyAll() is the safe default; Condition objects allow precise signalling.
• BlockingQueue implements producer–consumer without any of this ceremony.