Inter-thread Communication: wait, notify, notifyAll

Synchronization alone prevents threads from stepping on each other, but it does not let threads coordinate based on changing conditions — for example, a consumer thread that must pause until a producer thread has data ready. Java's Object class provides three methods for exactly this purpose: wait(), notify(), and notifyAll(), collectively known as inter-thread communication.

Why it matters

Sometimes a thread must not just exclude others but wait for them: a consumer waits for a producer, a worker waits for a signal. wait() and notifyAll() are the low-level mechanism for that. They have two rules that are easy to break — call them only while holding the lock, and always wait in a loop — and breaking either produces bugs that appear only occasionally.

The Rules: Must Be Called From a Synchronized Context

wait(), notify(), and notifyAll() can only be called by a thread that currently holds the monitor of the object they are invoked on — that is, from inside a block or method synchronized on that same object. Calling any of them outside a synchronized context throws IllegalMonitorStateException. Calling wait() releases the monitor and puts the thread into the WAITING state until another thread calls notify() or notifyAll() on that same object; the waiting thread then re-acquires the monitor before continuing.

• wait() — releases the lock and waits until notified (or interrupted, or a timeout elapses for the overloaded form).
• notify() — wakes up a single arbitrary thread waiting on this object's monitor.
• notifyAll() — wakes up all threads waiting on this object's monitor; each one competes to re-acquire the lock.

Why Use a while Loop, Not an if, Around wait()

A woken thread should always re-check its condition in a loop (while (conditionNotMet) { obj.wait(); }) rather than trusting a single check, because of "spurious wakeups" (the JVM is permitted to wake a waiting thread without an actual notify) and because with notifyAll(), multiple threads wake up but only some of them may find the condition still true for them by the time they re-acquire the lock.

The Producer-Consumer Pattern

The canonical use case is a shared buffer where a producer thread adds items and a consumer thread removes them. The producer waits when the buffer is full; the consumer waits when the buffer is empty; each notifies the other after changing the buffer's state. This pattern is the conceptual foundation behind Java's higher-level BlockingQueue implementations, which handle this coordination internally.

Example

public class ProducerConsumerDemo {
    private Integer item = null;

    public synchronized void produce(int value) throws InterruptedException {
        while (item != null) {
            wait(); // slot occupied, wait for consumer to take it
        }
        item = value;
        System.out.println("Produced: " + value);
        notifyAll(); // wake the consumer
    }

    public synchronized void consume() throws InterruptedException {
        while (item == null) {
            wait(); // nothing to consume yet
        }
        System.out.println("Consumed: " + item);
        item = null;
        notifyAll(); // wake the producer
    }

    public static void main(String[] args) throws InterruptedException {
        ProducerConsumerDemo buffer = new ProducerConsumerDemo();

        Thread producer = new Thread(() -> {
            try {
                for (int i = 1; i <= 3; i++) buffer.produce(i);
            } catch (InterruptedException ignored) {
            }
        });

        Thread consumer = new Thread(() -> {
            try {
                for (int i = 1; i <= 3; i++) buffer.consume();
            } catch (InterruptedException ignored) {
            }
        });

        producer.start();
        consumer.start();
        producer.join();
        consumer.join();
    }
}

Produced: 1
Consumed: 1
Produced: 2
Consumed: 2
Produced: 3
Consumed: 3
(The exact interleaving of "Produced"/"Consumed" lines is coordinated by wait/notify so each value
is consumed once, but timing details can vary slightly between runs.)

Exercise

Complete the Gate class. pass() must wait until the gate has been opened, and open() must open it and wake any waiting thread.

Expected output: opening then passed

class Gate {
    private boolean open = false;

    synchronized void pass() throws InterruptedException {
        // TODO: wait while the gate is not open
        System.out.println("passed");
    }

    synchronized void open() {
        // TODO: open the gate and wake up waiting threads
    }
}

public class GateDemo {
    public static void main(String[] args) throws InterruptedException {
        Gate gate = new Gate();

        Thread visitor = new Thread(() -> {
            try {
                gate.pass();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        visitor.start();

        System.out.println("opening");
        gate.open();
        visitor.join();
    }
}

class Gate {
    private boolean open = false;

    synchronized void pass() throws InterruptedException {
        while (!open) {
            wait();
        }
        System.out.println("passed");
    }

    synchronized void open() {
        open = true;
        notifyAll();
    }
}

public class GateDemo {
    public static void main(String[] args) throws InterruptedException {
        Gate gate = new Gate();

        Thread visitor = new Thread(() -> {
            try {
                gate.pass();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        visitor.start();

        System.out.println("opening");
        gate.open();
        visitor.join();
    }
}

Quick quiz

Interview questions