Difference between wait() and sleep()


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

Is my understanding that a wait()-ing Thread is still in running mode and uses CPU cycles but a sleep()-ing does not consume any CPU cycles correct?

Why do we have both wait() and sleep(): how does their implementation vary at a lower level?

7/27/2017 3:14:51 PM

Accepted Answer

A wait can be "woken up" by another thread calling notify on the monitor which is being waited on whereas a sleep cannot. Also a wait (and notify) must happen in a block synchronized on the monitor object whereas sleep does not:

Object mon = ...;
synchronized (mon) {

At this point the currently executing thread waits and releases the monitor. Another thread may do

synchronized (mon) { mon.notify(); }

(on the same mon object) and the first thread (assuming it is the only thread waiting on the monitor) will wake up.

You can also call notifyAll if more than one thread is waiting on the monitor – this will wake all of them up. However, only one of the threads will be able to grab the monitor (remember that the wait is in a synchronized block) and carry on – the others will then be blocked until they can acquire the monitor's lock.

Another point is that you call wait on Object itself (i.e. you wait on an object's monitor) whereas you call sleep on Thread.

Yet another point is that you can get spurious wakeups from wait (i.e. the thread which is waiting resumes for no apparent reason). You should always wait whilst spinning on some condition as follows:

synchronized {
    while (!condition) { mon.wait(); }
10/16/2018 11:22:27 PM

One key difference not yet mentioned is that while sleeping a Thread does not release the locks it holds, while waiting releases the lock on the object that wait() is called on.

synchronized(LOCK) {
    Thread.sleep(1000); // LOCK is held

synchronized(LOCK) {
    LOCK.wait(); // LOCK is not held

I found this post helpful. It puts the difference between Thread.sleep(), Thread.yield(), and Object.wait() in human terms. To quote:

It all eventually makes its way down to the OS’s scheduler, which hands out timeslices to processes and threads.

sleep(n) says “I’m done with my timeslice, and please don’t give me another one for at least n milliseconds.” The OS doesn’t even try to schedule the sleeping thread until requested time has passed.

yield() says “I’m done with my timeslice, but I still have work to do.” The OS is free to immediately give the thread another timeslice, or to give some other thread or process the CPU the yielding thread just gave up.

wait() says “I’m done with my timeslice. Don’t give me another timeslice until someone calls notify().” As with sleep(), the OS won’t even try to schedule your task unless someone calls notify() (or one of a few other wakeup scenarios occurs).

Threads also lose the remainder of their timeslice when they perform blocking IO and under a few other circumstances. If a thread works through the entire timeslice, the OS forcibly takes control roughly as if yield() had been called, so that other processes can run.

You rarely need yield(), but if you have a compute-heavy app with logical task boundaries, inserting a yield() might improve system responsiveness (at the expense of time — context switches, even just to the OS and back, aren’t free). Measure and test against goals you care about, as always.


There are a lot of answers here but I couldn't find the semantic distinction mentioned on any.

It's not about the thread itself; both methods are required as they support very different use-cases.

sleep() sends the Thread to sleep as it was before, it just packs the context and stops executing for a predefined time. So in order to wake it up before the due time, you need to know the Thread reference. This is not a common situation in a multi-threaded environment. It's mostly used for time-synchronization (e.g. wake in exactly 3.5 seconds) and/or hard-coded fairness (just sleep for a while and let others threads work).

wait(), on the contrary, is a thread (or message) synchronization mechanism that allows you to notify a Thread of which you have no stored reference (nor care). You can think of it as a publish-subscribe pattern (wait == subscribe and notify() == publish). Basically using notify() you are sending a message (that might even not be received at all and normally you don't care).

To sum up, you normally use sleep() for time-syncronization and wait() for multi-thread-synchronization.

They could be implemented in the same manner in the underlying OS, or not at all (as previous versions of Java had no real multithreading; probably some small VMs doesn't do that either). Don't forget Java runs on a VM, so your code will be transformed in something different according to the VM/OS/HW it runs on.


Here, I have listed few important differences between wait() and sleep() methods.
PS: Also click on the links to see library code (internal working, just play around a bit for better understanding).


  1. wait() method releases the lock.
  2. wait() is the method of Object class.
  3. wait() is the non-static method - public final void wait() throws InterruptedException { //...}
  4. wait() should be notified by notify() or notifyAll() methods.
  5. wait() method needs to be called from a loop in order to deal with false alarm.

  6. wait() method must be called from synchronized context (i.e. synchronized method or block), otherwise it will throw IllegalMonitorStateException


  1. sleep() method doesn't release the lock.
  2. sleep() is the method of java.lang.Thread class.
  3. sleep() is the static method - public static void sleep(long millis, int nanos) throws InterruptedException { //... }
  4. after the specified amount of time, sleep() is completed.
  5. sleep() better not to call from loop(i.e. see code below).
  6. sleep() may be called from anywhere. there is no specific requirement.

Ref: Difference between Wait and Sleep

Code snippet for calling wait and sleep method

    while(condition == true){ 
        monitor.wait()  //releases monitor lock

    Thread.sleep(100); //puts current thread on Sleep    

thread transition to different thread states


There are some difference key notes i conclude after working on wait and sleep, first take a look on sample using wait() and sleep():

Example1: using wait() and sleep():

synchronized(HandObject) {
    while(isHandFree() == false) {
        /* Hand is still busy on happy coding or something else, please wait */

/* Get lock ^^, It is my turn, take a cup beer now */
while (beerIsAvailable() == false) {
    /* Beer is still coming, not available, Hand still hold glass to get beer,
       don't release hand to perform other task */

/* Enjoy my beer now ^^ */

/* I have drink enough, now hand can continue with other task: continue coding */
synchronized(HandObject) {

Let clarity some key notes:

  1. Call on:
    • wait(): Call on current thread that hold HandObject Object
    • sleep(): Call on Thread execute task get beer (is class method so affect on current running thread)
  2. Synchronized:
    • wait(): when synchronized multi thread access same Object (HandObject) (When need communication between more than one thread (thread execute coding, thread execute get beer) access on same object HandObject )
    • sleep(): when waiting condition to continue execute (Waiting beer available)
  3. Hold lock:
    • wait(): release the lock for other object have chance to execute (HandObject is free, you can do other job)
    • sleep(): keep lock for at least t times (or until interrupt) (My job still not finish, i'm continue hold lock and waiting some condition to continue)
  4. Wake-up condition:
    • wait(): until call notify(), notifyAll() from object
    • sleep(): until at least time expire or call interrupt
  5. And the last point is use when as estani indicate:

you normally use sleep() for time-syncronization and wait() for multi-thread-synchronization.

Please correct me if i'm wrong.