First look at the traditional state transition diagram (this is what is used in the in-depth understanding of the Java virtual machine)
My doubt is that we know the lock is released when the wait() method is called. Then when notify is called, he needs to re-acquire the lock,
Isn't it necessary to enter the blocking queue to acquire the lock, then it should enter the blocked state. Why did he directly enter the running state?
I feel he is wrong. After the wait is awakened, it should first enter the blocked state, rather than directly entering Running.
I found a more comprehensive transition diagram about thread state (source: Java thread state and life cycle )
He is more correct
Thread is in the Blocked state while waiting for the monitor lock to enter a synchronized block or method or to reenter a synchronized block or method after calling Object.wait().
A thread is in the Blocked state while waiting for a monitor to lock into a synchronized block or method (synchronize) or re-enter a synchronized block or method after calling Object.wait() .
This is how people define it.
It can be understood in this way:
the blocking state is the state of waiting to acquire a lock. Object.wait() causes the thread to enter the Waiting state. Since the occupied CPU resources and locks are released when waiting() is called, when the Waiting thread is called by other threads Object.notify () After waking up, you need to re-acquire the lock on the object. At this time, it will also enter the Blocked state first.
For details on thread state transition, see here Java thread state and life cycle