Thread life cycle and thread states

"Hi, Amigo!"

"We're going to start a new topic: threads."

"Let's get started. Today we will examine the states that a Thread object passes through (or might pass through) when a thread is running."

"How many states can you name right now, Amigo?"

"Two. The first is a thread before the start() method is called: the object exists, but the thread isn't active yet. And the second is after the start() method has been called: when the thread is doing something important."

"You're right—there is such a distinction. These states are called new and running, but that's just the beginning."

"First, at some point the thread will finish running, which means there may be a situation where the Thread object exists, but the thread is not in the new or running state. "This state, where the thread has finished running, is called terminated."

"But there's more. Don't forget that at any given time only one thread is actually running. What appears to be simultaneous work is actually the processor constantly jumping from thread to thread. There is a separate state for when the thread seems to be running, but is actually waiting for its turn: it's called ready-to-run. As a thread works, it constantly switches from running to ready, and then back to running when it becomes active again."

"Immediately after the start() method is called, the thread is assigned the ready-to-run status and placed in a shared list of threads that the JVM switches between."

"That's not too difficult. Before it starts running, it has the new state. After it has finished, it is terminated. When it is running, the thread is in the running state; then when it is waiting, it's in the ready state."

"Your brevity is amazing, but you're right."

"But there's more. The thread can be blocked. For example, when you enter a synchronized block. If a thread gets to a code block marked as synchronized and another thread is using it, then our thread will enter the blocked state and will wait for the object's mutex (lock) to be released."

"Here's how this situation with states looks:"

"But there's more. There is also a separate state called waiting. This is when a thread is not blocked, but also not ready. For example, when you call the join() method on another thread."

When we call join() on an another Thread object, it's as if our thread «joins» it, but in reality it just waits for the other thread to finish.

"Additionally, there is also the wait() method (from the wait/notify/notifyAll trio of methods), which switches a thread to the waiting state when it is called."

"Whoa."

"Wait a minute! There's still more. A thread can sleep by calling the sleep method, for example. There is also a separate state for this. It's called «timed waiting». «timed waiting» means the thread is waiting for something for a limited time. If you call a wait method with a parameter, such as wait(timeout) or join(timeout), then the thread will enter the timed-waiting state."

"Here's the full diagram:"

"Hmm. Is that all? Or are there 10 more interesting states?"

"For now, that's it."

"In practice, you can just remember the first diagram. It's simpler. But the second is more accurate."

"Strangely enough, there are a lot of Thread state diagrams on the Internet, and they're all different."

"That's why I gave you this diagram—it's the most complete and correct."

"In this diagram, the ready and running states are combined in a single block called runnable. Do you know why?"

"No. It's the first time I've seen something like that."

"The Thread class has an inner class called State, as well as a public State getState() method."

public enum State
{
 NEW,
 RUNNABLE,
 BLOCKED,
 WAITING,
 TIMED_WAITING,
 TERMINATED;
}

"You can always call the getState() method on a Thread object, and find out its current state. And, of course, it will be one of the State enum values."

"I see. So, the real states are inside the JVM, but there are also states that you can access via Java code using the State getState() method."

"And under what circumstances would I use that?"

"Most likely, never."

"But you have to know what's going on inside threads. Otherwise, you'll have lots of bugs, and you won't even be able to guess what's causing them."

"Plus, employers love asking about Thread states during interviews."