Why wait() and notify() Must Be Called Inside synchronized

Every Java developer learns the rule early: call wait() and notify() only inside a synchronized block, or the JVM throws IllegalMonitorStateException. Far fewer can explain why the rule exists. It is not bureaucracy. Without that lock, a perfectly reasonable-looking consumer can go to sleep forever while the item it is waiting for sits right there in the queue. This guide takes the rule apart: the monitor it protects, the race it prevents, and the idioms and modern replacements that follow from it.

01The Rule and Its Exception

wait(), notify() and notifyAll() are final methods on java.lang.Object, so you can call them on any object. The compiler accepts them anywhere, and the language allows them anywhere. The JVM, however, checks one thing at runtime every time they are called: does the current thread own the monitor of the object the method is called on? If it does not, the call fails immediately.

Object lock = new Object();

lock.wait();
// java.lang.IllegalMonitorStateException: current thread is not owner

lock.notify();
// same exception: notify() is checked exactly the same way

The exception message differs between JDK versions (older releases print no message at all), but the cause is always the same. This is a runtime check, not a compile-time one. The compiler cannot verify ownership, because the lock may have been taken by a caller several frames up the stack:

private final Object lock = new Object();
private boolean ready;

void startAndAwait() throws InterruptedException {
    synchronized (lock) {
        awaitReady();              // lock owned here...
    }
}

private void awaitReady() throws InterruptedException {
    // ...so this is legal, even though no synchronized is visible here
    assert Thread.holdsLock(lock) : "caller must hold lock";
    while (!ready) {
        lock.wait();
    }
}

Thread.holdsLock(obj) is the standard way to document and assert that precondition in helper methods.

It must be the same object's monitor

Holding a lock is not enough. You must hold the monitor of the exact object you call wait() or notify() on. This is the most common way the exception shows up in code that "is synchronized":

Object a = new Object();
Object b = new Object();

synchronized (a) {
    b.notify();      // IllegalMonitorStateException: we own a, not b
}

public synchronized void consume() throws InterruptedException {
    while (queue.isEmpty()) {
        queue.wait(); // owns 'this' (synchronized method), not 'queue'
    }
}

A synchronized instance method locks this, so a bare wait() inside it (which means this.wait()) is fine. A static synchronized method locks the Class object, so a bare wait() there does not even compile: there is no this, and wait() is an instance method. You would have to call MyClass.class.wait(). The rule is always the same: synchronize on X, then call X.wait() / X.notify().

02Anatomy of a Monitor

To see why the check exists, you need to know what the JVM is protecting. Every Java object can act as a monitor. The JVM does not allocate the full structure until it is needed: an uncontended lock lives in a few bits of the object header, and the JVM "inflates" it to a full monitor when there is contention or when somebody calls wait(). Conceptually, though, each object has one.

A monitor has three areas a thread can be in:

• Entry set: threads that want to enter a synchronized block on this object while someone else owns it. Their state is BLOCKED.
• Owner: at most one thread, the one currently running inside a synchronized block on this object. It may hold the lock several times (reentrancy). The JVM tracks a hold count.
• Wait set: threads that called wait() on this object. Their state is WAITING (or TIMED_WAITING for wait(timeout)). They hold no claim on the lock at all.

That last sentence is the whole rule seen from the JVM's side. The entry set and the wait set are shared data structures. The monitor's own lock is what keeps them consistent, so only the owner may add itself to the wait set or move threads out of it.

03The Lost Wakeup Race

The JVM's internal bookkeeping explains part of the requirement. The more important reason is in your code. Every use of wait() has the same shape: check a condition, and if it does not hold, wait until someone changes it. The waker has the matching shape: change the state, then notify. These two sequences have to be atomic with respect to each other. If they are not, a notification can arrive in the gap between the check and the wait and be lost.

Imagine Java let you call wait() without the lock. A natural-looking consumer and producer would look like this:

// Consumer thread
if (queue.isEmpty()) {     // (1) check
    queue.wait();          // (5) wait -- in real Java this throws IMSE
}
Item item = queue.remove();

// Producer thread
queue.add(item);           // (3) change state
queue.notify();            // (4) signal

Now play one unlucky but perfectly legal interleaving. The scheduler can preempt a thread between any two operations, and nothing here forbids this one:

The consumer made a decision ("the queue is empty, so I should sleep") based on a fact that stopped being true before it acted on it. This is a classic check-then-act race. Here the "act" is going to sleep, and the cost is a thread that never wakes up, which in production looks like a hang with no exception, no CPU usage and no log line.

The fix: one lock around check, wait and signal

Now require both sides to hold the same monitor. The consumer's check and its call to wait() happen while it owns the lock, and the producer cannot add or notify without owning that same lock. The producer is therefore physically unable to run steps 3–4 until the consumer has either found an item or entered the wait set.

// Consumer
synchronized (queue) {
    while (queue.isEmpty()) {   // check under the lock
        queue.wait();           // release lock + enter wait set, atomically
    }
    item = queue.remove();      // still under the lock
}

// Producer
synchronized (queue) {
    queue.add(item);            // change state under the lock
    queue.notifyAll();          // signal under the lock
}

The crucial piece is that wait() releases the lock and joins the wait set as one atomic step. There is no moment where the consumer has let go of the lock but is not yet waiting. From the producer's point of view, the consumer is either still checking (so the producer is BLOCKED) or already in the wait set (so the producer's notification will find it).

The lock also makes the state visible

There is a second, quieter reason the lock matters: memory visibility. An unlock of a monitor happens-before every subsequent lock of that same monitor (JLS §17.4.5). When the producer adds an item and exits the block, and the consumer reacquires the lock on its way out of wait(), the consumer is guaranteed to see the producer's write to the queue. Without the lock, even a "correct" interleaving could leave the consumer reading a stale, cached view of the queue. The monitor gives you mutual exclusion and visibility together, and the wait/notify protocol depends on both.

if (queue.isEmpty()) {          // check: no lock held -- race window
    synchronized (queue) {
        queue.wait();           // wait: lock held -- no exception
    }
}

The synchronized block has to enclose the whole check-and-wait loop, not just the call. Keep this example in mind. It is also the answer to "why didn't the JVM designers just make wait() grab the lock itself?", which we come back to at the end.

04What wait() Actually Does

JLS §17.2.1 specifies wait() precisely. Let t be the calling thread, m the object, and n the number of times t currently holds m's lock (more than one if synchronized blocks on m are nested):

1. Ownership check. If n is zero, throw IllegalMonitorStateException. If the thread is already interrupted, throw InterruptedException instead of waiting.
2. Join the wait set and release fully. t is added to m's wait set and performs n unlock actions, releasing all reentrant holds, not just one. The thread becomes WAITING (or TIMED_WAITING).
3. Stay dormant until it is removed from the wait set by one of five events: notify() picks it, notifyAll(), interrupt(), the timeout elapses, or an implementation-specific spurious wakeup.
4. Reacquire. t performs n lock actions to restore its exact previous hold count. While it competes for the lock it is BLOCKED, just like any thread trying to enter synchronized.
5. Return, or if it was woken by an interrupt, clear the interrupt status and throw InterruptedException. Even then, the lock has already been reacquired, so your catch or finally code runs while holding it.

Two consequences surprise people. First, notify() does not release the lock. The notifier keeps ownership until it leaves its own synchronized block. The woken thread moves from WAITING to BLOCKED and must wait for that exit. Second, a woken thread gets no priority. It competes with every other thread in the entry set, including brand-new arrivals, and the JLS makes no fairness promise about who wins.

notify() picks an arbitrary thread

JLS §17.2.2: "There is no guarantee about which thread in the wait set is selected." It is not FIFO, not priority-based, and not something you can rely on even if one JVM version happens to behave in order. notifyAll() removes every thread from the wait set. They all move to BLOCKED and acquire the lock one at a time, each returning from wait() in turn.

wait() releases only one monitor

wait() releases the monitor of the object it is called on, and nothing else. If the thread also holds other locks (an outer synchronized on a different object, or a ReentrantLock), it keeps them while it sleeps. If the thread that would notify it needs one of those locks first, both threads stop forever. This is sometimes called nested monitor lockout. Avoid calling wait() while holding any lock other than the one you are waiting on.

synchronized (outer) {
    synchronized (inner) {
        while (!ready) {
            inner.wait();    // releases inner, still holds outer
        }
    }
}

// Notifier: blocks forever on 'outer', so it never reaches notify()
synchronized (outer) {
    synchronized (inner) {
        ready = true;
        inner.notifyAll();
    }
}

05Why while, Never if

Returning from wait() tells you only one thing: you were removed from the wait set and you own the lock again. It does not tell you that your condition predicate is true. There are three separate reasons it might be false:

• Spurious wakeups. The Object.wait Javadoc and JLS §17.2.1 explicitly allow a thread to wake with no notify, interrupt or timeout. That makes it simpler for the JVM to implement waiting efficiently on top of operating-system primitives that have the same allowance.
• Stolen wakeups. Between the notify() and the moment the woken thread reacquires the lock, other threads can get the lock first and consume the state the notification was about.
• Broadcasts. notifyAll() wakes every waiter, but often only one of them can proceed. And if one wait set serves several predicates (for example "not full" and "not empty"), a wakeup may have been meant for someone else entirely.

The stolen wakeup is the most instructive of the three, because it needs no unusual JVM behaviour, only ordinary scheduling:

Put together, every correct use of wait() follows this template:

synchronized (lock) {
    while (!conditionPredicate()) {
        lock.wait();
    }
    // predicate is true AND we hold the lock: act on the state
}

06notify() vs notifyAll()

notify() wakes one arbitrary waiter. notifyAll() wakes all of them. notify() looks like the efficient choice, and in a narrow set of cases it is. Outside those cases it can quietly stop your program.

Consider a bounded buffer with capacity 1. Producers and consumers synchronize on the same object, so they share one wait set, but they wait for opposite predicates: producers for "not full", consumers for "not empty". With notify(), this sequence is legal:

1. Consumers C1 and C2 call take() on the empty buffer and both wait.
2. Producer P1 puts an item and calls notify(), which happens to wake C1. C1 is now BLOCKED, waiting for the lock.
3. Before C1 runs, P1 tries to put again: buffer full, so it waits. P2 also tries to put: full, so it waits. Wait set: {C2, P1, P2}.
4. C1 gets the lock, takes the item (buffer now empty) and calls notify(). The JVM picks C2, another consumer.
5. C1 loops to take again: empty, so it waits. C2 gets the lock: empty, so it waits.
6. Wait set: {P1, P2, C1, C2}. Every thread is waiting and nobody is left to notify.

There is no cycle of threads holding locks the others need, so a classic deadlock detector will not report it. Thread dumps show every thread in WAITING (on object monitor). Because the outcome depends on which thread notify() happens to pick, the bug may appear only under load.

When notify() is safe

Use single notification only when both of these hold:

• Uniform waiters: every thread in the wait set waits on the same condition predicate and does the same thing when it wakes, so it does not matter which one is chosen.
• One in, one out: each state change enables at most one waiter to proceed, so waking one is enough.

A pool of identical worker threads waiting for "a task is available", where each submit() adds exactly one task, meets both conditions. A bounded buffer whose producers and consumers share one monitor does not. The safe default is notifyAll(). If profiling later shows the extra wakeups matter, the better fix is usually to give each predicate its own wait set using Condition objects (covered below), rather than gambling on notify().

07A Correct Bounded Buffer

Here is a version that combines the mistakes covered so far. It looks reasonable, it is synchronized, and it never throws IllegalMonitorStateException:

public class BrokenBuffer<T> {
    private final Queue<T> items = new ArrayDeque<>();
    private final int capacity;

    public BrokenBuffer(int capacity) { this.capacity = capacity; }

    public synchronized void put(T item) throws InterruptedException {
        if (items.size() == capacity) {   // BUG 1: if, not while
            wait();
        }
        items.add(item);
        notify();                         // BUG 2: may wake a producer
    }

    public synchronized T take() throws InterruptedException {
        if (items.isEmpty()) {            // BUG 1 again
            wait();
        }
        T item = items.remove();          // NoSuchElementException
        notify();                         // BUG 2 again
        return item;
    }
}
// BUG 3: the monitor is 'this' -- any caller can lock it or wait on it

Bugs 1 and 2 are covered above. Bug 3 is easier to miss. Synchronized methods lock this, and this is public. Any code holding a reference to the buffer can write synchronized (buffer) { ... } and hold it indefinitely, or call buffer.wait() and join your wait set, where it may receive one of your notify() calls and use up that signal. A private lock object makes the wait set an implementation detail that nobody outside the class can reach.

public final class BoundedBuffer<T> {
    private final Object lock = new Object();   // private monitor
    private final Deque<T> items = new ArrayDeque<>();
    private final int capacity;

    public BoundedBuffer(int capacity) {
        if (capacity <= 0) throw new IllegalArgumentException("capacity");
        this.capacity = capacity;
    }

    public void put(T item) throws InterruptedException {
        Objects.requireNonNull(item);
        synchronized (lock) {
            while (items.size() == capacity) {   // guard: not full
                lock.wait();
            }
            items.addLast(item);
            lock.notifyAll();                    // wake consumers
        }
    }

    public T take() throws InterruptedException {
        synchronized (lock) {
            while (items.isEmpty()) {            // guard: not empty
                lock.wait();
            }
            T item = items.removeFirst();
            lock.notifyAll();                    // wake producers
            return item;
        }
    }
}

Every access to items happens while holding lock, every wait is in a loop over its predicate, every state change is followed by notifyAll() on the same monitor, and nobody outside the class can touch the monitor. Whether notifyAll() is placed before or after the state change inside the block does not affect correctness, because no woken thread can run until the block exits. Placing it after the change is simply easier to read.

08Interrupts, Timeouts and sleep()

Do not swallow InterruptedException

Interruption is Java's cooperative cancellation signal. When a waiting thread is interrupted, it leaves the wait set, reacquires the lock, clears its interrupt status and throws InterruptedException. An empty catch discards the only record that someone asked this thread to stop.

synchronized (lock) {
    while (!ready) {
        try {
            lock.wait();
        } catch (InterruptedException e) {
            // ignored: cancellation request lost, loop waits again
        }
    }
}

There are two correct options. The first and simplest is to propagate: declare throws InterruptedException, as put/take above do. If you cannot (for example inside Runnable.run()), restore the flag and stop what you are doing, so code further up the stack can still see the request:

public void run() {
    synchronized (lock) {
        while (!ready) {
            try {
                lock.wait();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt(); // re-assert
                return;                             // and stop
            }
        }
        doWork();
    }
}

The JLS also guarantees that notifications are not lost because of interrupts (§17.2.4). If a thread is both notified and interrupted, it either returns normally with its interrupt still pending, or throws InterruptedException. More generally, after a notify() either at least one thread from the wait set returns normally from wait(), or every one of them exits by throwing InterruptedException. An interrupt cannot silently use up the signal.

Timed waits: wait(long)

wait(timeoutMillis) puts the thread in TIMED_WAITING and adds "the timeout elapsed" as a fifth way to leave the wait set. A few details matter:

• wait(0) means wait forever, not "don't wait". A negative timeout throws IllegalArgumentException.
• wait returns void, so it does not tell you whether it returned because of a timeout or a notification. You have to work out the remaining time yourself.
• After the timeout, the thread still has to reacquire the lock, so wait(100) can return well after 100 ms on a contended monitor.
• Spurious wakeups still apply, so a timed wait also needs a loop, this time with a deadline.

public T poll(long timeout, TimeUnit unit) throws InterruptedException {
    long remaining = unit.toNanos(timeout);
    final long deadline = System.nanoTime() + remaining;
    synchronized (lock) {
        while (items.isEmpty()) {
            if (remaining <= 0) {
                return null;                          // timed out
            }
            TimeUnit.NANOSECONDS.timedWait(lock, remaining);
            remaining = deadline - System.nanoTime(); // recompute
        }
        T item = items.removeFirst();
        lock.notifyAll();
        return item;
    }
}

TimeUnit.timedWait(obj, timeout) is a convenience wrapper over obj.wait(ms, nanos). Use System.nanoTime() rather than currentTimeMillis() for deadlines: it is monotonic and does not jump when the wall clock is adjusted.

wait() vs Thread.sleep()

Both pause the current thread, so they are often confused, but they do opposite things with locks:

Calling Thread.sleep() inside a synchronized block makes every other thread that needs the lock wait for the whole sleep. If you see sleep-polling a flag in a loop, that is usually a wait()/notifyAll() or a CountDownLatch waiting to be written.

09Lock, Condition and Beyond

Since Java 5, java.util.concurrent.locks offers an explicit version of the same idea. A Lock plays the role of the monitor's lock, and a Condition plays the role of a wait set. The difference is that one lock can have as many conditions as you need.

The rule from this article carries over. With ReentrantLock, calling await(), signal() or signalAll() without holding the lock throws IllegalMonitorStateException, for the same lost-wakeup reasons. The Condition interface allows implementations to impose this requirement, and ReentrantLock's conditions do. Spurious wakeups are allowed too, so the while loop stays.

public final class ConditionBuffer<T> {
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull  = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();
    private final Deque<T> items = new ArrayDeque<>();
    private final int capacity;

    public ConditionBuffer(int capacity) { this.capacity = capacity; }

    public void put(T item) throws InterruptedException {
        lock.lock();
        try {
            while (items.size() == capacity) {
                notFull.await();           // producers wait here
            }
            items.addLast(item);
            notEmpty.signal();             // wake exactly one consumer
        } finally {
            lock.unlock();
        }
    }

    public T take() throws InterruptedException {
        lock.lock();
        try {
            while (items.isEmpty()) {
                notEmpty.await();          // consumers wait here
            }
            T item = items.removeFirst();
            notFull.signal();              // wake exactly one producer
            return item;
        } finally {
            lock.unlock();
        }
    }
}

Separate conditions fix the "wrong kind of waiter" problem structurally. Only producers ever wait on notFull and only consumers on notEmpty, so each wait set is uniform, and each put or take enables exactly one thread of the other kind. That meets both conditions for single notification, so signal() is safe here where notify() was not. ArrayBlockingQueue in the JDK uses this same two-condition design.

In practice: use java.util.concurrent

Hand-written wait/notify code is mostly found in libraries, older codebases and interviews. For application code, the JDK already ships well-tested versions of the patterns above, and they handle all of the issues covered here internally:

BlockingQueue<Order> queue = new ArrayBlockingQueue<>(100);
queue.put(order);              // blocks while full
Order next = queue.take();     // blocks while empty
Order maybe = queue.poll(2, TimeUnit.SECONDS);   // timed

CountDownLatch ready = new CountDownLatch(3);
ready.countDown();             // each worker, when initialised
ready.await();                 // coordinator: wait for all three

Semaphore permits = new Semaphore(10);
permits.acquire();             // at most 10 concurrent holders
try { callDownstream(); } finally { permits.release(); }

LockSupport: the primitive underneath

LockSupport.park() and unpark(thread) are the low-level building blocks that ReentrantLock, Condition and most of java.util.concurrent are built on. They do not need a lock. Instead of a wait set they use a per-thread permit: unpark makes the permit available, and park consumes it, returning immediately if it is already available. So an unpark that arrives before the park is not lost, which is exactly the lost-wakeup case that notify() gets wrong. The permit holds at most one, though: two unparks before a park leave a single permit. park may also return spuriously. Code using it still loops on a predicate kept in volatile or atomic state, and it is rarely the right tool outside library code.

10Why wait() Doesn't Lock Itself

A reasonable question after all this: if wait() needs the lock, why does the JVM throw an exception instead of quietly acquiring the lock inside wait()? Because that would not help. The lock has to protect your condition check, and the check is in your code, before the call:

The same reasoning applies on the notify side. A notification only means something if it is tied to a state change that waiters can observe. Requiring the notifier to own the monitor forces the state change and the signal into a critical section that cannot interleave with a waiter's check-and-wait, and the lock's happens-before edge makes the change visible to the waiter that wakes up.

So the IllegalMonitorStateException is a cheap, partial check. The JVM cannot prove that your predicate was checked under the lock (that is your job), but it can at least refuse a wait or notify that clearly is not part of any critical section on that object. Monitors in other languages follow the same pattern: POSIX pthread_cond_wait takes the mutex as an argument and requires the caller to have locked it, for the same reason.

11Interview Questions