Why do wait(), notify() and notifyAll() live on java.lang.Object rather than on Thread, and what rule governs calling them?

## The core idea: monitors belong to objects In Java, **every object** has an associated **intrinsic lock**, also called a **monitor**. `synchronized(obj)` acquires `obj`'s monitor. Alongside the lock, each object also has a **wait-set**: a holding area for threads that have voluntarily paused, waiting for some condition tied to that object to become true. Threads in Java don't coordinate by talking to each other directly; they coordinate **through a shared object** — a queue, a buffer, a latch. The natural home for 'pause until something changes about *this object*' is therefore the **object itself**, which is why `wait()`, `notify()`, and `notifyAll()` are defined on `java.lang.Object` rather than on `Thread`. If they lived on `Thread`, you'd be waiting on a *thread*, which doesn't match the mental model of guarding shared state. ## The mandatory rule: hold the monitor You may call these three methods **only while holding the object's monitor** — i.e., from inside a `synchronized` block or method on that same object. Otherwise the JVM immediately throws **`IllegalMonitorStateException`** (an unchecked exception). This is required because the methods manipulate the monitor's wait-set, which is only safe under the lock. ```java synchronized (queue) { // hold queue's monitor while (queue.isEmpty()) { // guard loop, not an if queue.wait(); // releases monitor, parks in queue's wait-set } item = queue.remove(); } ``` ## What each method does - **`wait()`**: *atomically* releases the monitor and parks the current thread in the object's wait-set. Releasing the lock is essential — otherwise no other thread could change the state being waited on (deadlock). When later notified and rescheduled, the thread **re-acquires the monitor** before `wait()` returns. - **`notify()`**: wakes **one** arbitrary thread from the wait-set. The woken thread doesn't run immediately — it must re-acquire the monitor first (the notifier still holds it until it leaves the synchronized region). - **`notifyAll()`**: wakes **all** waiting threads; they then contend to re-acquire the monitor one at a time. Generally **safer** than `notify()` because `notify()` can wake the 'wrong' thread (one whose condition still isn't satisfied) and lose a wakeup. ## Why the guarded loop (`while`, not `if`) Two reasons you must re-check the condition after `wait()` returns: 1. **Spurious wakeups**: a thread can wake from `wait()` without any `notify()` — the spec explicitly permits this. 2. **Stale condition**: between `notify()` and the woken thread re-acquiring the lock, another thread may have changed the state (e.g., consumed the item). So the condition that was true at notify time may be false again. Hence the canonical pattern is `while (!condition) obj.wait();`. ## Why they're `final` The methods are `final` on `Object` so the **monitor protocol is fixed and uniform** for every object — the runtime implements wait/notify in the JVM, and allowing overrides would let a class corrupt the locking semantics that other code and the JVM depend on. ## Modern note This is the low-level primitive. Higher-level utilities (`ReentrantLock` + `Condition`, `BlockingQueue`, `CountDownLatch`, `Semaphore`) are usually preferable, but they're built on these same happens-before/monitor concepts, so understanding wait/notify remains foundational.