Back to Java Course

In Java, threads can have States. The Thread.State enum defines the different states that a Java thread can have.

This enum defines the following values

• NEW
• RUNNABLE
• BLOCKED
• WAITING
• TIMED_WAITING
• TERMINATED

States of a Java Thread

NEW

This is the default state a thread gets when it is first created.

RUNNABLE

As soon as a thread starts executing, it moves to the RUNNABLE state. Note that a thread that is waiting to acquire a CPU for execution is still in this state.

BLOCKED

A thread moves to the BLOCKED state as soon as it gets blocked waiting for a monitor lock. This can happen in one of the following two ways

• It's waiting to acquire a lock to enter a synchronized block/method.
• It's waiting to reacquire the monitor lock of an object on which it invoked the Object.wait method.

WAITING

A thread moves to this state as a result of invoking one of the following methods

• Object.wait without a timeout
• Thread.join without a timeout
• LockSupport.park

TIMED_WAITING

A thread moves to this state as a result of invoking one of the following methods

• Thread.sleep
• Object.wait with a timeout
• Thread.join with a timeout
• LockSupport.parkNanos
• LockSupport.parkUntil

TERMINATED

As soon as a thread terminates, it moves to this state.

Possible state transitions

As soon as a thread gets scheduled for execution, it moves to the RUNNABLE state. This transition has been shown with the first arrow (marked as 1).

From the RUNNABLE state, a thread can move to any of the BLOCKED, WAITING, TIMED_WAITING, or TERMINATED state.

Theoretically speaking, if a thread does not wait to acquire any lock, or does not sleep, or does not invoke any of the methods which makes it wait, it just finishes its execution and directly goes to the TERMINATED state (marked as 2d).

Of course in a practical application, the above scenario is highly unlikely. Often a thread tries to acquire a lock, in which case it moves to the BLOCKED (marked as 2a) state if it has to wait for the lock.

Threads also explicitly wait for some preconditions to be true/actions from other threads, in which case they move to the WAITING (marked as 2b) or the TIMED_WAITING (marked as 2c) state, depending on whether the waits were timed or not.

Once a thread moves to the BLOCKED state, the only possible transition that is allowed next is to move to the RUNNABLE state (marked as 3d).Similarly, the only possible transition from the WAITING state is to move to the BLOCKED state (marked as 3c).

Please note that some of the articles on the internet incorrectly adds a transition from the WAITING to the RUNNABLE state. This is just not correct.

A thread can never move to the RUNNABLE state from the WAITING state directly.

We can understand the reason for this with an example.Suppose that we have a thread T which is currently in the RUNNABLE state and holds the monitor lock of three objects a, b, and c, as shown in the diagram below.

At this point, T invokes c.wait(), after which it no longer holds the monitor lock of object c

As soon as T is notified using an invocation of notify/notifyAll, it stops waiting and competes with other threads (let's say, X and Y) to acquire the monitor lock of c

which, according to the definitions above, is the BLOCKED state. Only after acquiring the monitor lock of c, T moves to the RUNNABLE state.

Similar reasoning can be applied for the Thread.join() (which internally uses Object.wait()) and LockSupport.park().

Let's get back to our original state transition diagram. As we can see, a thread can move to either the RUNNABLE (marked as 3b) or the BLOCKED (marked as 3a) state from the TIMED_WAITING state.

The transition to RUNNABLE is possible in this case because a thread can enter the TIMED_WAITING state after invoking the Thread.sleep method, in which case it retains all the monitor locks it currently holds.

As a thread finishes execution after moving back and forth between the RUNNABLE, BLOCKED, WAITING or TIMED_WAITING state, it moves to the TERMINATED state once and for all.

How do we get the current state of a Thread?

We can use the Thread.getState() method to retrieve the current state of a thread. We can use this value to monitor or debug any concurrency issues that our application might face in production.

sleep()

• If a thread doesn't want to perform any operation for a particular amount of time that is just pausing is required then we should go for sleep() method.
• 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.
• It is a static and native method. It is not a final method.
• It can be overloaded and throws InterruptedException also.

join()

• If a thread wants to wait until completing other threads then we should go for join() method.
• It is a final method. It is not a static method, and it is not a native method (it's implemented in Java internally using wait()).
• It can be overloaded and throws InterruptedException.

yield()

• It causes to pause current executing thread to give the chance for remaining waiting threads of same priority.
• 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.
• It is static method and native method but not final method.
• It doesn't throw InterruptedException and it can't be overloaded.

wait()

• wait() method releases the lock.
• wait() is the method of Object class.
• wait() is the non-static method.
• wait() should be notified by notify() or notifyAll() methods.

Difference between wait and sleep method

• A wait can be "woken up" by another thread calling notify on the monitor which is being waited on whereas a sleep cannot it can only be interrupted.
• While sleeping a Thread does not release the locks it holds, while waiting releases the lock on the object that wait() is called on.
• 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. wait() says "I'm done my timeslice. Don't give me another timeslice until someone calls notify()."
• we can normally use sleep() for time-synchronization and wait() for multi-thread-synchronization.