wait, notify, notifyAll

## The problem these solve Sometimes a thread cannot make progress until some *condition* becomes true — e.g. a consumer cannot take from an empty queue until a producer adds an item. Busy-waiting (looping and re-checking while holding CPU) wastes cycles. Java provides a way for a thread to **block until notified**, releasing the CPU in the meantime. This is the `wait`/`notify`/`notifyAll` mechanism. ## Key terms, defined from scratch - **Monitor / intrinsic lock:** every Java object has an associated lock (a 'monitor'). Entering a `synchronized` block on an object acquires that object's monitor; leaving releases it. Only one thread can hold a given monitor at a time. - **Wait-set:** each monitor also has an associated *wait-set* — a holding area of threads that have called `wait()` on that object and are parked, not competing for the lock. - **These three methods are on `java.lang.Object`**, not Thread, because the lock and wait-set belong to *objects*. Any object can be used as a condition variable. ## What each call does - **`obj.wait()`**: (1) verifies the current thread holds `obj`'s monitor; (2) **atomically releases** that monitor and suspends the thread, placing it in `obj`'s wait-set. When the thread is later woken, (3) it must **re-acquire** `obj`'s monitor before `wait()` returns — so on return it again holds the lock. There are overloads `wait(long timeoutMillis)` and `wait(long, int nanos)` that also wake after the timeout elapses. - **`obj.notify()`**: moves **one** arbitrary thread from `obj`'s wait-set to the runnable state (it still has to re-acquire the lock before proceeding). Which one is unspecified. - **`obj.notifyAll()`**: moves **all** threads in `obj`'s wait-set to runnable; they then contend for the lock one at a time. ## The mandatory precondition You must **own `obj`'s monitor** when calling any of the three — i.e. be inside `synchronized(obj){ ... }` (or a synchronized instance method calling `this.wait()`, or a synchronized static method using the Class object). If you call them without holding that exact monitor, the JVM throws `IllegalMonitorStateException` at runtime. This rule exists because the check-condition-then-wait sequence must be atomic: you check the guard *while holding the lock*, and `wait()` releases it atomically so no signal can slip in between the check and the park (the 'lost wakeup' it prevents). ## Spurious wakeups and the guarded-loop rule A thread in `wait()` may return **without** any `notify` having occurred — a *spurious wakeup*, permitted by the JVM/OS for implementation reasons. Also, by the time a notified thread re-acquires the lock, another thread may have already consumed the condition. Therefore the condition must be **re-checked in a loop**: ```java synchronized (lock) { while (!conditionHolds()) { // while, never if lock.wait(); } // condition is true AND we hold the lock } ``` Using `if` here is the classic bug: a spurious wakeup or a stale notify lets the thread proceed with the condition false. ## notify vs notifyAll `notify()` wakes one waiter and is cheaper, but is only safe when **all** waiters are interchangeable and waiting on the **same** condition — otherwise you can wake the 'wrong' thread (one whose condition is still false), which goes back to sleep while the thread that *could* proceed is never woken (a stuck system). `notifyAll()` is the safe default: every waiter wakes, re-checks its guard, and only the eligible ones proceed; the rest loop back to `wait()`. The cost is a 'thundering herd' of wakeups contending for the lock. ## Why it's largely legacy From `java.util.concurrent` you usually prefer higher-level tools: `BlockingQueue` for producer-consumer, `CountDownLatch`/`CyclicBarrier`/`Semaphore` for coordination, or `Lock` + `Condition` (`await`/`signal`/`signalAll`) which gives multiple named wait-sets per lock. But `wait`/`notify` remains the foundation interviewers probe.