Thread.sleep() vs Object.wait() — Lock Release, Recipients, and When to Use Each

Both pause a thread, but they behave completely differently around locks.

`Thread.sleep(ms)` — a static method on `Thread`

• Pauses the current thread for at least the given duration
• Does not release any held locks — if you're in a synchronized block, you still own it
• Thread state: TIMED_WAITING
• Wakes on timeout or interrupt
• Throws InterruptedException

`Object.wait()` — an instance method on every `Object`

• Must be called while holding that object's monitor — i.e., inside synchronized(obj)
• Otherwise throws IllegalMonitorStateException
• Atomically releases the monitor and parks the thread
• Another thread must reacquire the monitor and call obj.notify() or notifyAll() to wake it
• When it resumes, reacquires the monitor before returning

Why the lock release matters

• Producer-consumer: a full queue's producer calls wait(), releasing the lock so a consumer can enter take(), remove an item, and notifyAll()
• If wait() kept the lock, the system would deadlock immediately
• sleep() can't be used as a substitute here for exactly that reason

The spurious wakeup rule

• JVM spec explicitly allows wait() to return even without notify() or timeout
• Reason: OS condition variables like pthread_cond_wait allow it, and hiding it would be costly
• Therefore: `wait()` must always be in a `while` loop that re-checks the predicate
• Using if is a classic bug — a spurious wakeup proceeds with invalid state

In modern code I rarely write raw `wait`/`notify`

• ReentrantLock + Condition.await() — same semantics, multiple condition variables, try-lock
• BlockingQueue (LinkedBlockingQueue, ArrayBlockingQueue) — hides the whole pattern
• LockSupport.park() — low-level primitive underlying j.u.c
• CompletableFuture — for async composition

Other gotchas

• Both throw InterruptedException — handle it by rethrowing or resetting the interrupt flag; don't swallow silently
• sleep() inside synchronized holds the lock for the entire sleep — watch for contention
• Thread.sleep(0) is a yield hint, not truly zero

Recommendation: Never use sleep() for coordination — it's a delay, not a signal. Use wait()/notify() only if you're maintaining legacy code or building a custom synchronizer. For any new concurrent code, reach for `BlockingQueue` for producer-consumer, `ReentrantLock` + `Condition` for multi-condition signaling, or `CompletableFuture` for async flows. The monitor-release semantics of wait() are what make synchronized useful for coordination — once you understand that, the rest of Java's concurrency primitives make sense.