When a thread has been instantiated but not started (in other words, the
start()method has not been invoked on the Thread instance), the thread is
said to be in the newstate. At this stage, the thread is not yet considered to be
alive. Once the start()method is called, the thread is considered to be alive
(even though the run()method may not have actually started executing yet). A
thread is considered dead(no longer alive) after the run()method completes. The
isAlive()method is the best way to determine if a thread has been started but has
not yet completed itsrun() method.
Prior to calling start() on a Thread instance, the thread (when we use
lowercase t, we're referring to the thread of execution rather than the Thread class)
is said to be in the new state as we said. The new state means you have a Thread
objectbut you don't yet have a true thread.So what happens after you call start()?
The good stuff:
---> A new thread of execution starts (with a new call stack).
---> The thread moves from the new state to the runnable state.
---> When the thread gets a chance to execute, its target run() method will run.
My first question is (I think before to understand second question I must get the point of my first question)
So What does K&B book want to express by saying "the new state".
Let me take a step back and explain the thread states in more detail.
A thread has various states during its lifetime. Three basic thread states to understand are – new, runnable and terminated. We will discuss more thread states a bit later.
A program can access the state of the thread using Thread.State enumeration. The Thread class has the getState() instance method which returns the current state of the thread. Here is an example:
This program prints:
Just after the creation of the thread and just before calling the start() method on that thread, the thread is in the new state. After calling the start() method, the thread is ready to run or is in the running state (which we cannot determine); so it is in runnable state. From the main() method, we are calling t.join(). The main() method waits for the thread t to die. So once the statement t.join() successfully gets executed by main() thread, it means that the thread t has died or terminated. So, the thread is in the terminated state now.
A word of advice: be careful about accessing the thread states using the getState() method. Why? By the time you acquire information on a thread state and print it, the state could have changed! I know the last statements could be confusing. To understand the problem with getting thread state information using the getState() method, consider the previous example. In one sample run of the same program, it printed the following:
Note the italicized part of the output, the statement after printing “Just after calling t.start();”. In the initial output, we got the thread state (as expected) as RUNNABLE state. However, in another execution of the same program without any change, it printed the state as TERMINATED. Why? In this case, the thread is dead before we could get a chance to check it and print its status! [Note that we have not implemented the run() method in the BasicThreadStates class, so the default implementation of the run() method does nothing, and terminates quickly.]
A thread can also be in blocked, waiting, timed_waiting states—which we’ll discuss now. I've attached a figure with this post which shows how and when the state transitions typically happen for these six states. You can use Thread.State enumeration which has the list of possible thread states. Here is a simple program that prints the value of the states in this enumeration: