Java thread state transition, WAITING to BLOCKED, or RUNNABLE?

Question

There seems to be a discrepancy between SO consensus and nearly every Java thread state diagram on the Internet; specifically, regarding thread state transition from WAITING after notify() or notifyAll() is invoked...

• WAITING never goes directly to RUNNABLE
• The thread is WAITING until it is notified...Then it becomes BLOCKED...
• Once this thread is notified, it will not be runnable...This is..Blocked State.

So the concensus on SO is: a thread transitions from WAITING to BLOCKED after invoking notify() or notifyAll(); diagram below illustrates this transition in green.

Question

Why do most state diagrams on the web illustrate the transition from WAITING to RUNNABLE, not BLOCKED? Depiction in red shows the incorrect transition; am I missing something?

Answer 1

Any diagram that shows a notify invocation bringing a thread from WAITING to RUNNABLE is wrong (or is using an unclarified shortcut). Once a thread gets awoken from a notify (or even from a spurious wakeup) it needs to relock the monitor of the object on which it was waiting. This is the BLOCKED state.

Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait.

This is explained in the javadoc of Object#notify():

The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object.

and Object#wait()

The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

Answer 2

I am focusing on the problem recently.

as the Oracle document Thread.State says we can use LockSupport.park() to put the current thread into 'WAITING' or 'TIMED_WAITING' state.

so when you try the LockSupport.unpark(), the specified thread will return to 'RUNNABLE' from 'WAITING'/'TIMED_WAITING'. (I am not sure whether it will go through the 'BLOCKED' state)

Answer 3

A thread is in WAITING state goes in BLOCK state,until it acquires monitor by notify and become RUNNABLE.

Same applies for TIMEDWAITING,it goes in BLOCK state,if monitor is hold by some other thread,even though specified time has passed.(your diagram need to be corrected)

Answer 4

It is worth to mention that is also true for Thread.interrupt() method during WAITING state while in lock.wait() method.

Thread.interrupt() method will firstly make WAITING thread BLOCKED with isInterrupted flag set to true, and only after reacquiring lock interrupted thread will be able to throw InterruptedException (that is obvious, as it cannot handle exception, by that continuing execution without having exclusive lock before). (example here)

Simply to say

Always WAITING -> BLOCKED to be able again compete for the lock, and after that to acquire it eventually and run its' code RUNNABLE.