Shulou(Shulou.com)06/02 Report--

This article focuses on "how to understand the Java thread life cycle", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the Java thread life cycle.

If we want to talk about the life cycle of Java threads, I think we should first talk about the thread life cycle of the operating system.

Because JVM runs on top of the operating system, it cannot be bypassed, and it can be said that threads in Java are essentially threads of the operating system.

If you are smart, you must have found that both operating systems, Java and C # have the concept of threads. Between them, there must be something in common about the life cycle of threads, otherwise, the operating system has its own set of life cycle processes, Java has its own set, and C # has its own set, and they have to be able to cooperate with each other.

So let's take a look at what the general thread life cycle has.

First, go directly to the picture (A Fan's picture, is it okay?):

As you can see, there are mainly five states: new, ready, running, waiting and terminated.

Where:

New simply says that the thread has been created, but it is not yet allowed to allocate CPU execution. Because this state only means that you have been created at the programming language level, and the operating system level has not been created, it is certainly impossible to assign CPU execution.

The state of ready means that it has been successfully created at the operating system level, so the next step is to wait for the allocation CPU to execute. Remember that classic sentence? ready? go!

The status of running, I believe you will know, I have already ready, at this time if you assign me a CPU, I can go? Isn't that the running status?

Waiting state, that is, when the thread is in the running state, it suddenly finds out, hey, I need to do an running O operation, or I need to wait for an event to occur (for example, I need a condition variable). At this time, I can no longer continue the running of happy. What are we going to do? waiting it.

Then you have already waiting. Should you release the CPU resources you occupy? Therefore, threads in waiting state never have a chance to get the right to use CPU.

Did you freak out at the words "never have a chance"? I don't think I'll ever have a chance to execute it. Don't worry, you are in waiting. When your wait incident happens, you can continue to running status.

When the entire thread finishes execution, or when an exception occurs, it enters the terminated state, that is, the thread's mission is completed, and the thread in the terminated state will not switch to another state.

The general thread life cycle and how to switch between them should be clearer at this point.

Next, let's take a look at the life cycle of Java threads, how they are optimized on this basis, and what's the difference.

Life cycle of Java threads

Let's first take a look at the state of the source code definition (I've removed all the comments to highlight the point):

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

You can clearly see that there are six thread states defined in the source code. How many general states are there just now? five, right? now it's six.

What are these six for? I have figured out the five states just now and the switch between them. How do they switch between these six states?

Don't worry, Fan is so sweet that he must have drawn a picture:

We also look at these six states separately:

From NEW to RUNNABLE, it should be easy to understand that thread calls the start method.

The Thread object just created by Java is the NEW state. There are two main ways to create a Thread object, one is to inherit the Thread object, override the run () method, and the other is to implement the Runnable interface, override the run () method, and take the implementation class as a parameter to create the Thread object.

But remember, NEW just said that if this thread is created at the programming language level and not created at the operating system level, it will certainly not be scheduled by the operating system, let alone execute it.

So if the Java thread wants to execute, it must transition to the RUNNABLE state, that is, thread calls the start method.

RUNNABLE and BLOCKED move from the RUNNABLE state to the BLOCKED state if the thread waits for an implicit lock from synchronized. Because the synchronized-decorated method / code block allows only one thread to execute at a time, other threads have to wait. When the waiting thread acquires the synchronized implicit lock, it will move from the BLOCKED state to the RUNNABLE state.

Is there a question here? That is, when a condition occurs in wait, the thread will go to the waiting state at the operating system level. What about at the JVM level? At the JVM level, the state of Java threads does not change. That is, at this time, the state of the Java thread is still RUNNABLE.

RUNNABLE and WAITING state transition, I feel that the diagram has been said very well, I will not repeat it here.

RUNNABLE and TIMED_WAITING state transition, I feel that the diagram is already very good, and I will not repeat it here. After careful observation, we will find that TIMED_WAITING has more timeout parameters than WAITING. After all, TIMED_WAITING has a time limit to wait.

From RUNNABLE to TERMINATED, this process is easy to understand. After executing the run () method, the thread automatically reaches the TERMINATED state. Of course, if an exception is thrown during the execution of the run () method, it will also cause the thread to terminate.

Sometimes we may need to force the execution of the run () method to be interrupted. What should we do? Do you use the stop () method or the interrupt () method? The correct pose is to call the interrupt () method

The stop () method really kills the thread without giving the thread a chance to catch its breath. If the killed thread holds the synchronized implicit lock, it will never release the lock again, and the next thread will not be able to acquire the synchronized implicit lock. Is that particularly dangerous? Similarly, suspend () and resume () are not recommended.

The interrupt () method is much softer than the stop () method, it just informs the thread that subsequent operations do not have to be performed, the thread can choose not to execute now, of course, it can also choose to stop after a period of time, or I don't listen to you, it doesn't matter if I have to finish, it doesn't matter, interrupt () just informs you. For example, if you want to take a train to a place and suddenly inform you that the train is late, you can choose to ignore the notice and wait, or choose another high-speed train, but no matter what you do, it has nothing to do with the railway station. It has done its duty.

It should be clearer to see here.

In the Java thread life cycle, the RUNNABLE state combines the ready and running states, while the BLOCKED, WAITING and TIMED_WAITING states are actually the waiting states, that is, the thread has to wait for certain events to occur before it can continue to execute.

At this point, I believe you have a deeper understanding of "how to understand the Java thread life cycle". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.