wait(), notify(), notifyAll().

Hook: These methods are the “knock, unlock, and wake everyone in the room” tools of Java concurrency — and interviewers love them because one small mistake can freeze an entire app.

Question: What are wait(), notify(), and notifyAll() in Java?

Answer: They are methods on Object used for thread coordination through an object's monitor, which is the lock tied to synchronized. wait() makes the current thread release that lock and sleep until another thread signals it; notify() wakes one waiting thread; notifyAll() wakes all waiting threads. They must be called while holding the same object's monitor, or Java throws IllegalMonitorStateException.

Interview-Ready Answer: I use wait(), notify(), and notifyAll() for low-level thread coordination on an object's monitor. wait() releases the lock and pauses the thread until it is signaled, while notify() wakes one waiting thread and notifyAll() wakes every waiting thread on that monitor. The key detail is that all of them must be called inside a synchronized block on the same object, and in real code I usually guard wait() with a loop because spurious wakeups can happen.

What these methods really do

Detailed Explanation: Think of every Java object as having a built-in waiting room called a monitor (the lock used by synchronized). These methods are not general thread commands; they are ways for threads to cooperate using that monitor. The big idea is simple: one thread waits until some condition becomes true, and another thread changes the condition and signals it.

1. A thread enters a synchronized(obj) block and checks a condition, such as “is the queue empty?”
2. If the condition is not ready, it calls obj.wait(). This does two things at once: it releases obj's monitor and parks the thread in WAITING state.
3. Another thread enters a synchronized block on the same object, changes the shared state, and calls notify() or notifyAll().
4. The waiting thread is moved from the wait set to the entry set, but it does not run immediately. It must first re-acquire the same monitor lock.
5. When it finally regains the lock, it wakes up, re-checks the condition, and continues if the condition is truly ready.

That re-check is essential because a thread can wake up for reasons other than your notification, and because another thread may have grabbed the condition first.

Why wait() must be in a loop

wait() can return even if nobody intended it to proceed. This is called a spurious wakeup, which means “it woke up without a real signal.” Also, even after a real wakeup, the condition may no longer be true by the time the thread gets the lock again. The safe pattern is:

1. Acquire the lock.
2. Check the condition in a while loop.
3. Call wait() if the condition is not satisfied.
4. After waking, check again.

notify() vs notifyAll()

notify() chooses one arbitrary waiting thread on that monitor. You do not get to pick which one. That is why notify() is easy to use incorrectly when different threads are waiting for different conditions. notifyAll() wakes every waiting thread; they race to reacquire the lock, then each thread re-checks the condition and only the correct one proceeds.

Rules interviewers expect you to know

1. Same monitor: the thread must own the object's monitor when calling any of these methods.
2. Only on shared state: use them to coordinate access to shared mutable data, not as a general sleep tool.
3. Prefer higher-level tools: in modern Java, BlockingQueue, CountDownLatch, Semaphore, and Lock/Condition are usually safer.
4. Notify after state change: update the condition first, then signal.

Performance note: signaling itself is roughly O(1), but notifyAll() can cause a “thundering herd” where many threads wake up, fight for the lock, and go back to sleep. That extra contention can be expensive under load, especially with dozens or hundreds of waiters.

Edge cases and gotchas

1. IllegalMonitorStateException: thrown if you call wait(), notify(), or notifyAll() without owning the monitor.
2. Lost signal pattern: if you check a condition outside synchronized, another thread can change it before you wait, and you may sleep forever.
3. Nested locks: wait() releases only the monitor of the object you call it on, not any other locks you hold.
4. Interrupted threads: wait() throws InterruptedException, so the waiting code must handle cancellation cleanly.

Memory Hook: “wait = leave the room, notify = tap one shoulder, notifyAll = shout to everyone — but nobody moves until they get the key back.”

Real-world story

Real-World Example: Imagine a checkout service in an e-commerce app where worker threads pull orders from a shared buffer. When the buffer is empty, consumers call wait() and stop burning CPU. When a producer thread receives a new order from the API, it adds the order, updates the shared state, and calls notifyAll() so any waiting consumer can wake up and compete for the item.

What goes wrong if you misunderstand it: A team uses notify() while multiple consumer types are waiting on the same monitor, such as “normal orders” and “priority orders.” The wrong thread wakes repeatedly, finds its condition still false, and goes back to waiting while the right thread stays asleep. In production, logs show threads stuck in WAITING, orders pile up, latency climbs, and autoscaling does not help because the bug is not lack of threads — it is bad signaling.

Follow-up & Tricky Questions:

• Why must wait() be inside a while loop? Because wakeups can be spurious, and because another thread may change the condition before you regain the lock. The loop re-checks the real state, which is the only safe source of truth.
• What is the difference between a monitor and a lock? In Java here, the monitor is the built-in lock attached to every object and used by synchronized, wait(), and notify(). People often say “lock” casually, but the exact wait/notify mechanism is tied to the object monitor.
• Why does notify() sometimes cause bugs while notifyAll() works? notify() wakes one arbitrary waiter, which may be a thread whose condition is still false. notifyAll() wakes everyone so each thread can re-check its own condition, which is safer when multiple conditions share the same monitor.
• What happens after a thread is notified? It does not run immediately. It must first compete to re-acquire the monitor, and only then can it continue past wait().
• Can wait() release all locks the thread holds? No. It releases only the monitor of the object it is waiting on. Any other locks the thread holds remain held, which can cause deadlocks if you are not careful.
• Why not use Thread.sleep() instead? sleep() just pauses a thread for time; it does not release a lock and it does not coordinate with another thread. wait() is about condition-based communication.
• Is notifyAll() always better? Not always. It is safer, but it can wake many unnecessary threads and create contention. In simple single-condition designs, notify() can be fine if you can prove only one kind of waiter exists.
• Does wait() belong to Thread? No, and this is a classic trap. It belongs to Object because the coordination is tied to the monitor of the shared object, not to the thread itself.
• Does notify() choose the longest-waiting thread? No guarantee is given. The JVM decides which waiting thread to wake, so you should never rely on ordering.
• Can a thread miss a notification? Yes, if you write the code incorrectly and check the condition outside the synchronized region. That is why the condition check, wait, and state update must be done under the same monitor.

Common Mistakes:

• Calling wait() or notify() outside synchronized: this throws IllegalMonitorStateException. Correction: always own the same monitor before calling them.
• Using if instead of while: a thread may wake up too early or the condition may change before it runs. Correction: re-check the condition in a loop.
• Using notify() when multiple conditions share one monitor: the wrong waiter may wake and make no progress. Correction: prefer notifyAll() unless you can prove single-condition waiting.
• Forgetting to update shared state before notifying: waking first can let another thread observe stale state. Correction: change the condition, then signal.

Memory Hook: “Wait = let go, Notify = tap one, NotifyAll = wake the room, and always re-check the door before entering.”

Cheat Sheet:

• wait() releases the object's monitor and blocks.
• notify() wakes one arbitrary waiting thread.
• notifyAll() wakes all waiting threads on that monitor.
• All three require owning the same monitor via synchronized.
• Use while, not if, around wait().
• Prefer higher-level concurrency tools in new code.

Practice Tasks:

• Modify the demo to use notify() instead of notifyAll() and observe why it becomes risky with multiple consumers.
• Add a timeout version of wait() and log when a consumer gives up waiting.
• Rewrite the buffer using BlockingQueue and compare how much simpler it becomes.