wait() vs sleep()

JavaMidjava

The Question

What is the difference between wait() and sleep() in Java?

What a Strong Answer Covers

• wait() in Object releases lock must be in synchronized block
• sleep() in Thread does not release lock
• wait() for inter-thread communication
• sleep() for time delay
• both throw InterruptedException

Senior-Level Answer

wait() and sleep() both pause thread execution, but they serve entirely different purposes and behave very differently with respect to locks.

sleep(long millis) is a static method on Thread. It suspends the current thread for the specified duration, or until interrupted. Critically, sleep() does not release any locks or monitors the thread holds. It is used for rate limiting, polling delays, or scheduling — it has nothing to do with inter-thread coordination.

wait() is an instance method on Object. It must be called from within a synchronized block on the object being waited on. When called, it atomically releases the monitor lock on that object and suspends the thread. The thread remains suspended until another thread calls notify() or notifyAll() on the same object, or until the optional timeout expires. After being notified, the thread re-acquires the lock before proceeding.

This atomic release-and-wait property is why wait() is used for condition-based coordination. The classic producer-consumer pattern: the consumer calls synchronized(queue) { while (queue.isEmpty()) queue.wait(); }, releasing the lock so the producer can enter the synchronized block and call queue.notifyAll().

Both methods throw InterruptedException, which must be handled. Both should be called in a while loop that re-checks the condition, not an if statement — to guard against spurious wakeups (OS-level interruptions where wait() returns without being notified).

In modern Java, wait/notify is largely replaced by higher-level concurrency utilities: Condition (from java.util.concurrent.locks.Lock) provides await()/signal()/signalAll() with the same semantics but more flexibility, and BlockingQueue handles the producer-consumer pattern without any manual synchronization. wait/notify is still important to understand for interviews and when maintaining legacy code.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying wait() is defined on Thread — it is defined on Object, because the lock being released belongs to the object's monitor.
• Not mentioning spurious wakeups and the requirement to call wait() in a while loop checking the condition.
• Not knowing that sleep() holds all locks — this is a classic deadlock trap when sleep() is called inside a synchronized block.

Follow-Up Questions

• Why is wait() defined on Object rather than Thread? — The lock (monitor) belongs to the object, not the thread. Releasing the lock is an operation on the object's monitor, so wait() logically belongs to Object.
• What is a spurious wakeup and how do you guard against it? — The OS can wake a waiting thread without notify() being called. Always wrap wait() in a while loop re-checking the condition: while (!condition) object.wait();
• How does java.util.concurrent.locks.Condition improve on wait/notify? — Condition allows multiple wait queues per lock, provides timed await with TimeUnit, and the signal/await methods have clearer semantics tied to a specific Lock rather than any object monitor.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main