Describe the different processing states that apply to executing threads
Java Thread States
Once a thread has been started, it may not execute immediately, and when it does, it rarely executes all the way through to completion. This is because the thread must share the system's CPU or CPUs with other threads.
A thread can be only in one of five states
New: This is the state the thread is in after the Thread instance has been created but the start() method has not been invoked on the thread. It is a live Thread object, but not yet a thread of execution. At this point, the thread is considered not alive.
Runnable: This is the state a thread is in when it is eligible to run but the scheduler has not selected it to be the running thread.
A thread first enters the runnable state when the start() method is invoked, but a thread can also return to the runnable state after either running or coming back from a blocked, waiting, or sleeping state. When the thread is in the runnable state, it is considered alive.
Running: This is where the action is. This is the state a thread is in when the thread scheduler selects it from the runnable pool to be the currently executing process.
A thread can transition out of a running state for several reasons, including because "the thread scheduler felt like it." We will look at those other reasons shortly. There is only one way to get to the running state: The scheduler chooses a thread from the runnable pool.
Waiting/blocked/sleeping: This is the state a thread is in when it is not eligible to run. This is really three states combined into one, but they all have one thing in common:
The thread is still alive, but is currently not eligible to run. In other words, it is not runnable, but it might return to a runnable state later if a particular event occurs. A thread may be blocked waiting for a resource (like I/O or an object's lock), in which case the event that sends it back to runnable is the availability of the resource.
For example, if data comes in through the input stream the thread code is reading from, or if the object's lock suddenly becomes available. A thread may be sleeping because the thread's run code tells it to sleep for some period of time, in which case, the event that sends it back to runnable causes it to wake up because its sleep time has expired
Dead: A thread is considered dead when its run() method completes. It may still be a viable Thread object, but it is no longer a separate thread of execution.
Once a thread is dead, it can never be brought back to life. If you invoke start() on a dead Thread instance, you will get a runtime (not compiler) exception. If a thread is dead, it is no longer considered alive.
The following table describes the circumstances under which a thread may move from one state to another:
The thread is started as a separate execution sequence.
The thread's run() method completes its processing.
The thread invokes its sleep() method.
The thread is blocked on I/O.
The thread waits for a lock on an object or class.
The thread invokes the wait() method of an object.
A sleep() timeout has been expired. An I/O operation is completed.
The thread acquires a lock for which it had been waiting.
The thread is notified that an object for which it had been waiting has become available.
A thread's interrupt() method is invoked.
In addition to the names listed above, there are other names for thread states.
Learning how a thread transitions from one state to another is key to mastering multithreading. The following MouseOver tooltip and the remainder of this module describe these state transitions.