background
Master multithreading, concurrency, locking is an excellent programmer necessary knowledge, they are based on threads and meaningful, familiar with and understand the mechanism of threads is very important.
Today we are going to talk about, how many states does a thread have?
If you surf the Internet, you’ll see a lot of different terms: 5 states, 6 states, 7 states, New, Ready, Executable, Run, block, lock pool, suspend, interrupt, wait, end, die, stagnation.
Java-defined state
If you open Thread and find the enumeration below it, State, you’ll see that JAVA defines only six states:
- New (New)
- Runnable (run)
- Blocked.
- Waitting (Wait indefinitely)
- Timed Watting
- Terminated
The translation of the state nouns here refers to “Understanding the Java Virtual Machine in Depth” by Zhiming Zhou.
I will analyze these states one by one and explain why there are so many states above
New (New)
A new thread object is created, but the start() method has not yet been called.
Runnable (run)
Runnable includes Running and Ready in operating system threads
- Ready to go
After the thread object is created, other threads, such as the main thread, call the start() method of the object
A thread in this state is in the runnable thread pool, waiting to be selected by thread scheduler to acquire CPU usage, that is, to be eligible to be run by the CPU
- A thread in the ready state is converted to Running after obtaining a CPU time slice.
Blocked.
While waiting to acquire an exclusive lock (e.g. Synchronized), this event occurs when another thread abandons the lock
Waitting (Wait indefinitely)
Threads in this state are not allocated CPU execution time and are not given a display to wake up without waiting for other threads, after a certain amount of time they are automatically woken up by the system
The following method puts the thread into an indefinite wait state
- Object.wait() without Timeout
- Thread.join() without Timeout
(Timed Waitting)
Threads in this state are not allocated CPU execution time and are not given a display to wake up without waiting for other threads, after a certain amount of time they are automatically woken up by the system
The following method puts the thread into a finite wait state
- Thread.sleep()
- Object.wait() with Timeout
- Thread.join() with Timeout set
- LockSupport. ParkNanos () method
- LockSupport. ParkUnit () method
Terminated
Terminated thread status. The thread has been terminated
State transition
- Below is the state transition diagram of the Deep Understanding JAVA Virtual Machine thread
The above diagram is easier to understand, but doesn’t expose much of the details of the running state
- Let’s look at the next picture
This diagram maps the running state (transition between running and ready states), the internal state that the CPU schedules. There is no explicit definition in the JAVA state enumeration
Answers to confusing questions
What is the cause of so many nouns?
- Noun translation problem
- Terminated is translated as “termination,” but its meaning is similar to death, and the language used is called “Dead.”
- Meaning to confuse
- For example, the internal states in Runnable, Ready and Running, are the two states that CPU scheduling cares about, but the enumeration wants to block them.
- For example, the method thread.suspend () translates to suspend. Some students say that a Thread has a suspended state, which is obviously treating an action as a state without understanding the state of the Thread
What is a lock pool? What waiting pool? What is a wait queue? What is a synchronous queue? What’s the difference between these?
So if you think about it for yourself, let’s say there are 10 threads, and there’s a way to synchronize a block of code, and only one thread can enter at a time, right? So the other nine threads are blocked, so where are those nine threads?
After the first thread runs, the other blocked threads have to compete, right? So we say that blocked threads are put into the lock pool, so how to implement the lock pool? If you think about it this way, it’s a queue, which is called a synchronous queue.
And by analogy, what is a waiting pool, a waiting queue? In fact, it’s the same as the previous lock pool, synchronization queue.
I haven’t found any official information about lock pool and synchronous queue on Google.
Why is it true that some blogs unify the three states of Time Waiting, Waitting, and Blocked into Blocked?
If we look at it another way, when the thread is in a Time Waiting state, is the thread doing anything? Waitting while the thread is working? Is the Blocked thread doing any work?
(3) Wait/Notify is Waitting, Synchronized is Blocked. But isn’t he essentially a thread that doesn’t work?
So I think there is some truth to the above question, so why does JAVA distinguish between these states?
In B, an answer seems to be the right one. The original text is here, teacher Zhao’s answer
I’ll give you a quick summary here
- Blocked is a past participle, meaning he is stuck (innocent, full of tears). Because this code only lets one thread run. At the same time, the JVM knows how to end Blocked, and as soon as another thread exits the code, it automatically lets you in. This means that other threads don’t need to wake you up; the JVM does it automatically.
- Waiiting is when I call wait() and actively block myself (I’m waiting for a baifumei), and ask the JVM to wake me up after a certain condition (let’s meet tonight), such as another thread calling notify(). The responsibility for this wake-up call lies with other threads explicitly calling some wake-up function.
This distinction is made by the JVM for management purposes. For example, a thread with two causes is managed in two queues (the synchronization queue and the wait queue mentioned above). If another thread is running synchronized, I simply need to block the queue and release it. And someone called notify(), I just need to Waitting out of the queue.
Article Reference:
- For an explanation of thread states, see “Understanding JAVA Virtual Machines in Depth” – Zhiming Zhou
- The second thread state transition diagram from: https://blog.csdn.net/pange1991/article/details/53860651/