Do you know? Threads in Java actually have 6 states

The first thing to tell you is that the 5 states on the web are misleading, and threads in Java actually have 6 states. The statement of 5 states is actually the state of the early process.

Status of the early process:

The so-called " process State" refers to the early " single-threaded process" state.

For the "multithreaded process" that is now common, it is clear that talking about "process state" is meaningless, and you should talk about "the state of a thread under process" or "thread state" directly. However, sometimes the "process state" and "thread state" are mixed to say.

Some systems call threads "lightweight Processes" (light-weight process), so they're still talking about "process state."

Sometimes they are not even called "processes" or "threads", which are called "task" or "job".

The difference from the traditional running state

Some people often feel that the Java thread state is still missing a running state, which is actually the two different levels of the state confused. In the case of Java thread state, there is no so-called running state, and its runnable state contains the running state.

We may ask why the JVM does not differentiate between these two states.

The current time (time-sharing) multitasking (multi-task) operating system architecture is usually done using the so-called "temporal quantum or timing slice" approach preemptive (preemptive) round-robin (Round-robin).

This time shard is usually very small, a thread at most can only run on the CPU at a time (at this point in the running state), that is, about 0.01 seconds of this magnitude, time slices will be switched down into the end of the dispatch queue to wait for another dispatch. (Return to Ready state)

In general, Java's thread state is service-monitored, and if the thread is switched so fast, then it doesn't make much sense to differentiate between ready and running.

Today's mainstream JVM implementations have Java thread one by one mapped to the underlying operating system thread, the dispatch entrusted to the operating system, we see at the virtual machine level is the essence of the underlying state mapping and packaging. The JVM itself does not have to do any real scheduling, the bottom of the ready and running state mapping up also does not have much meaning, therefore, unification becomes runnable state is a good choice.

Here is the comment in the Thread.state source code:

These states is virtual machine states which don't reflect any operating system thread states.

These states are virtual machine states , and it does not reflect the thread state of any operating system.

Notes for the runable state:

A thread in the runnable state was executing in the Java Vsan but it could be waiting for other resources From the operating system such as processor.

A thread in the runnable state is executing in a Java virtual machine, but it may be waiting for other resources from the operating system, such as a processor.

The RUNNABLE state in Java actually contains the state of ready and running, so you can completely ignore the inaccurate statements on the Internet, the answer to this question is often in the source code and Javadoc.

Status in 6:
New (newly created)
RUNNABLE (can be run)
BLOCKED (blocked)
Waiting (Infinite Wait)
Timed_waiting (Deadline waiting)
TERMINATED (termination)

Related articles:

Java instance-Get thread state

Several state sharing in Java threads