Java wait(), notify() and notifyAll(): Producer Consumer Guide

In Java, the wait(), notify() and notifyAll() methods of Object let threads coordinate on shared state. A thread calls wait() to release an object’s monitor and pause until another thread calls notify() or notifyAll() on the same object.

We use the three methods when one thread must wait for a change made by another thread, for example a consumer that waits for tasks in a queue, or a producer that waits for free space. They are the low-level building blocks behind classes such as BlockingQueue, and we still meet them in older code and in interviews.

The following example lets one thread add a task to taskQueue and notify, while the main thread waits in a loop until the queue is not empty.

List<Integer> taskQueue = new ArrayList<>();
Thread.ofPlatform().start(() -> {
    synchronized (taskQueue) {
        taskQueue.add(7);
        taskQueue.notifyAll();          // wakes the threads waiting on taskQueue
    }
});
int task;
synchronized (taskQueue) {
    while (taskQueue.isEmpty()) {
        taskQueue.wait();               // releases the monitor until notified
    }
    task = taskQueue.remove(0);
}
int received = task;                    // 7

Both threads synchronize on the same object, and the waiting thread checks the condition in a while loop. We first look at what each method does, build a bounded producer and consumer queue, compare notify() with notifyAll() and replace the hand-written code with java.util.concurrent classes. For a shorter comparison with the sleep method, see our sleep vs wait article.

1. What Are wait(), notify() and notifyAll() Methods?

Every Java object has a monitor, and a thread owns it while it runs inside synchronized on that object. The monitor also has a wait set, which is the group of threads that called wait() on the object and have not woken up yet. The three methods are final methods of Object that move threads into and out of that wait set.

All three methods have the same rule. The calling thread must own the monitor of the object, or the call throws IllegalMonitorStateException.

1.1. wait()

The wait() method releases the monitor of the object and puts the current thread in the WAITING state. The overloads wait(long timeoutMillis) and wait(long timeoutMillis, int nanos) use TIMED_WAITING and give up after the timeout. The thread leaves the wait set for one of four reasons.

• Another thread calls notify() and the JVM picks this thread.
• Another thread calls notifyAll().
• The timeout ends, if we passed one.
• Another thread interrupts it, so wait() throws InterruptedException, or it wakes up spuriously, that is, without any of the other reasons.

Before wait() returns, the thread takes the monitor back, so the code after it always runs inside the synchronized block again. Because a thread can wake up while the condition is still false, we always call wait() in a while loop that checks the condition.

1.2. notify()

The notify() method wakes up one thread from the wait set of the object, and the Java specification does not say which one. The call does not release the monitor. The woken thread moves to the queue for the monitor and runs only after the notifying thread leaves its synchronized block.

So if the notifier still works for ten seconds inside its synchronized block after notify(), the woken thread waits those ten seconds too. If no thread is waiting, notify() does nothing and the signal is lost.

1.3. notifyAll()

The notifyAll() method wakes up every thread in the wait set of the object. The threads still run one at a time, because each of them must take the monitor back before wait() returns. Thread priority does not decide the order, so we never write code that depends on which thread runs first.

In a print server, for example, five printer threads wait on a job queue. When an admin cancels all jobs, the queue calls notifyAll() once, and every printer thread wakes up, sees the empty queue and goes back to waiting.

2. How to Use wait(), notify() and notifyAll() in Java

The producer and consumer problem is the classic use case. A producer adds tasks to a queue with a fixed capacity, and a consumer removes them. The producer must wait while the queue is full, and the consumer must wait while it is empty.

The following example keeps the logic in one class, TaskQueue, with a capacity of 2. The producer adds tasks 1 to 5 and the consumer takes five tasks, so both threads finish and we can check the result.

2.1. The Shared Queue

Both methods are synchronized, so they lock the TaskQueue object, and wait() and notifyAll() are called on this. Each method waits in a loop for its own condition and notifies after it changes the list.

class TaskQueue {
    private final List<Integer> tasks = new ArrayList<>();
    private final int capacity;

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

    synchronized void put(int task) throws InterruptedException {
        while (tasks.size() == capacity) {
            wait();                      // queue full, the producer waits
        }
        tasks.add(task);
        notifyAll();                     // wakes a waiting consumer
    }

    synchronized int take() throws InterruptedException {
        while (tasks.isEmpty()) {
            wait();                      // queue empty, the consumer waits
        }
        int task = tasks.remove(0);
        notifyAll();                     // wakes a waiting producer
        return task;
    }
}

We call notifyAll() here because producers and consumers wait on the same object for different conditions. With notify(), a producer could wake another producer instead of a consumer, which we look at in section 3.

2.2. Producer and Consumer Threads

The producer and the consumer are plain lambdas. Each one catches InterruptedException and restores the interrupt flag, so the thread stops cleanly if someone interrupts it while it waits.

TaskQueue queue = new TaskQueue(2);
List<Integer> consumed = Collections.synchronizedList(new ArrayList<>());

Thread producer = Thread.ofPlatform().name("producer").start(() -> {
    try {
        for (int i = 1; i <= 5; i++) {
            queue.put(i);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

Thread consumer = Thread.ofPlatform().name("consumer").start(() -> {
    try {
        for (int i = 1; i <= 5; i++) {
            consumed.add(queue.take());
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});

producer.join();
consumer.join();
List<Integer> result = List.copyOf(consumed);   // [1, 2, 3, 4, 5]

2.3. What Happens at Runtime

The consumer gets the tasks in order, and the list never holds more than two tasks. How often each thread waits differs from run to run, because the scheduler decides when each thread runs.

• If the consumer starts first, it finds an empty list, calls wait() and releases the monitor.
• The producer adds task 1 and calls notifyAll(), which moves the consumer to the queue for the monitor.
• When the list holds two tasks, the producer waits in put() until the consumer removes one and notifies.

Neither thread pauses inside its synchronized block. A pause there keeps the monitor for the whole delay and blocks the other thread for no reason, so we leave delays out of synchronized code.

3. Choosing Between notify() and notifyAll()

The choice depends on who waits on the object. The notifyAll() method is the safe default, and notify() is an optimization for one specific case.

Question	notify()	notifyAll()
Threads woken	One, chosen by the JVM	All threads in the wait set
Safe when waiters wait for different conditions	No, it can wake the wrong thread	Yes
Safe when all waiters are the same kind and one change lets only one continue	Yes	Yes, with extra wake-ups
Cost	One wake-up	Every waiter wakes, checks the condition and most wait again

Say a TaskQueue with a capacity of 1 has two producers and one consumer, and the queue is full, so both producers wait. The consumer takes the task and calls notify(), which wakes producer A, and comes back for the next task, finds the queue empty and waits. Producer A adds a task, and its notify() wakes producer B instead of the consumer. Producer A tries to add its next task and waits, producer B sees a full queue and waits too, and since nobody is awake, all three threads wait forever.

With notifyAll(), the consumer is always among the woken threads, so it makes progress. If we need targeted wake-ups without that risk, a Lock with two Condition objects gives each kind of thread its own wait set.

4. Replacing wait() and notify() in Java 25 Code

The java.util.concurrent package, added in Java 5, already contains tested versions of most wait and notify patterns. For example, the whole TaskQueue class becomes one line with an ArrayBlockingQueue, whose put() and take() block in the same way.

BlockingQueue<Integer> jobs = new ArrayBlockingQueue<>(2);
jobs.put(1);
jobs.put(2);
boolean added = jobs.offer(3, 50, TimeUnit.MILLISECONDS);   // false, queue full
int first = jobs.take();                                     // 1

When we need our own condition logic, ReentrantLock with Condition replaces the monitor methods. Each Condition has its own wait set, so signal() wakes a thread that waits for that condition only.

class BoundedBuffer {
    private final Deque<Integer> items = new ArrayDeque<>();
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notEmpty = lock.newCondition();
    private final Condition notFull = lock.newCondition();

    void put(int item) throws InterruptedException {
        lock.lock();
        try {
            while (items.size() == 2) {
                notFull.await();
            }
            items.addLast(item);
            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    int take() throws InterruptedException {
        lock.lock();
        try {
            while (items.isEmpty()) {
                notEmpty.await();
            }
            int item = items.removeFirst();
            notFull.signal();
            return item;
        } finally {
            lock.unlock();
        }
    }
}

BoundedBuffer buffer = new BoundedBuffer();
buffer.put(4);
int item = buffer.take();               // 4

Most hand-written wait and notify code in business apps falls into four patterns, and each one has a ready-made class.

• A queue between threads uses a BlockingQueue.
• Waiting until several tasks finish uses a CountDownLatch or ExecutorService.close().
• Waiting for one result uses a CompletableFuture.
• Custom conditions use a Lock and Condition from the Lock API.

Old code with wait() and notifyAll() also works on virtual threads. Since Java 24 (JEP 491), a virtual thread that waits inside synchronized releases its carrier thread, so there is no need to rewrite such code only because of virtual threads. Other coordination classes, such as Semaphore and Phaser, are grouped in the Java concurrency guide.

5. wait(), notify() and notifyAll() FAQs

Lost signals, spurious wakeups and the order of woken threads are the parts of wait and notify that interviewers probe most.

5.1. What happens when notify() is called and no thread is waiting?

Nothing. The notification is lost, because the monitor does not remember it. A thread that calls wait() later waits for the next notification, which is why the waiting thread checks a shared condition before it calls wait().

5.2. Can there be a race condition while wait() releases or reacquires the lock?

No. The JVM adds the thread to the wait set and releases the monitor as one atomic step, so a notification sent right after the release reaches the thread. On the way back, wait() returns only after the thread owns the monitor again.

5.3. If a thread receives a notification, is the condition guaranteed to be true?

No. Between the notification and the moment the thread gets the monitor back, another thread can take the monitor first and change the state, for example a second consumer that takes the only task. Spurious wakeups also return without any notification. The while loop checks the condition again and waits once more if it is false.

5.4. Which thread gets the notification when several threads wait?

The specification leaves it open. Which thread notify() wakes depends on the JVM and on timing, and thread priority gives no guarantee. When the choice matters, we call notifyAll() and let each thread check its own condition, or use separate Condition objects.

5.5. Does notifyAll() wake up all threads at the same time?

All waiting threads leave the wait set, but they do not run in parallel. Each one must take the monitor back, so they continue one after another, and only after the notifying thread leaves its synchronized block.

5.6. Why wake up all threads if only one of them can continue?

Because the waiting threads may wait for different conditions, such as producers waiting for space and consumers waiting for tasks. With notifyAll(), the thread that can continue is always woken, and the others go back to waiting after checking their condition.

5.7. Why are wait() and notify() defined in Object and not in Thread?

Because they work with the monitor of an object, and every object has one. A thread waits on the object that holds the shared state, such as a queue, so the methods belong to that object. Calling them on a Thread object is a bad idea, because the JDK uses the Thread monitor for join().

6. Conclusion

The wait() method releases an object’s monitor and pauses the thread, notify() wakes one waiting thread and notifyAll() wakes all of them. Every call needs the monitor of the same object, and every wait() sits in a while loop that checks the condition.

We prefer notifyAll() when threads wait for different conditions, and keep pauses out of synchronized blocks. For new code, BlockingQueue, Lock with Condition, CountDownLatch and CompletableFuture give the same coordination with less room for lost signals.

7. References

• Object Javadoc (Java 25)
• JLS 25, Wait Sets and Notification
• Condition Javadoc (Java 25)
• Oracle Java Tutorial, Guarded Blocks

Happy Learning !!

Source Code on Github