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

This article mainly explains why java does not use the stop method to stop threads. 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 why java doesn't use the stop method to stop threads.

After the thread is started, it may need to be terminated at run time. The termination method provided by Java has only one stop, but I do not recommend this method because it has the following three problems: (1) the stop method is outdated in terms of Java coding rules, and obsolete methods are not recommended. (2) the stop method will cause the code logic to be incomplete. The stop method is a "malicious" interrupt. Once the stop method is executed, it terminates the currently running thread, regardless of whether the thread logic is complete or not, which is very dangerous. Look at the following code:

The logic of this code is like this: the child thread is an anonymous inner class whose run method hibernates for 1 second and then executes the subsequent logic, while the main thread terminates the operation of the child thread after sleeping for 0.1 seconds, that is, when JVM executes thread.stop (), the child thread is still executing sleep (1000), and the stop method clears the information in the stack and terminates the thread This also leads to the incomplete logic of the run method. The output statement println represents a piece of logic, which may be very important, such as the main logic of the child thread, resource recovery, scenario initialization, etc., but because the stop thread is no longer executed, the business logic is incomplete. This is extremely dangerous because we don't know when the child thread will be terminated, and stop cannot even guarantee basic logical integrity. And this operation is also very hidden, where the child thread execution will be closed is difficult to locate, which brings a lot of trouble for future maintenance. (3) stop method destroys atomic logic multithreading in order to solve the problem of preemption of shared resources, the concept of lock is used to avoid resource asynchrony, but for this reason, stop method will bring more trouble: it will discard all locks, resulting in damage to atomic logic. For example, there is a program like this:

MultiThread implements the Runnable interface and has multithreading capability. Synchronized code block is added to the run method, which indicates that the atomic logic is internal. It will first increase and then decrease according to the rules of synchronized synchronous code block. At this time, no matter how many threads are started, the printed result should be astat0. However, if an executing thread is stop, the atomic logic will be broken. The code is as follows:

The first thing to note is that all threads share an instance variable t of MultiThread, and then because synchronization blocks are added to the run method, only one thread can enter the synchronized block. The execution order of this code is as follows: 1) Thread T1 starts and executes the run method. Since no other thread holds the lock of the synchronous code block, the T1 thread begins to sleep after it is added to the sleep method. 2) JVM starts five more threads and runs the run method at the same time. Due to the blocking effect of the synchronized keyword, these five threads cannot perform self-increment and self-subtraction operations, waiting for the T1 thread lock to be released. 3) the main thread executes the t1.stop method, terminating the T1 thread. Note that since variable an is shared by all threads, the other five threads get variable an as well. 4) the other five threads in turn get the opportunity to execute CPU and print out a value. After analyzing so much, I believe readers also understand the results of the output, and the results are as follows:

It was originally expected that the logic in the synchronized synchronization code block is atomic logic, free from the interference of external threads, but as a result, the atomic logic is destroyed, which is an important reason why the stop method is abandoned: it destroys the atomic logic. Since you can't use the stop method to terminate a thread, how can you terminate a running thread? The answer is also simple, using custom flag bits to determine the execution of the thread, the code is as follows:

This is a very simple way to determine whether the thread body needs to stop running, which can ensure the logical integrity of the thread body, and will not destroy the atomic logic. Some readers may be familiar with Java API and ask: doesn't Thread also provide a way for interrupt to interrupt threads? This method is not an outdated method, can it be used? Can it terminate a thread? Very good question, interrupt, the name looks a lot like a way to terminate a thread, but I can tell you very clearly that it is not, it cannot terminate an executing thread, it just modifies the interrupt flag, such as the following code:

When you execute this code, you will find that there is always Running output and will never stop. It seems that there is no change in executing interrupt. That is because the interrupt method cannot terminate the state of a thread. It will only change the interrupt flag bit (if you output t1.isInterrupted () before and after t1.interrupt (), you will find that false and true are output respectively). If you need to terminate the thread, you need to make your own judgment. For example, we can use interrupt to write more concise and safe code for terminating threads.

In short, if you expect to terminate a running thread, you cannot use the outdated stop method and need to code the implementation yourself, so that the atomic logic will not be broken and the code logic will not be abnormal. Of course, if we are using a thread pool (such as the ThreadPoolExecutor class), we can gradually shut down the threads in the pool through the shutdown method, which uses a more gentle and safe method of thread closure without the drawbacks of the stop method at all.

At this point, I believe you have a deeper understanding of why java does not use the stop method to stop threads, so 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.