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

Answer 1

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 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

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.