Java Interrupt mechanism detailed

1. Introduction

When we click on the cancellation button of an antivirus software to stop the virus, when we typed the Quit command at the console to end a background service ... Requires a thread to cancel a task that another thread is performing. Java does not provide a safe and straightforward way to stop a thread, but Java provides an interrupt mechanism.

If you do not have a comprehensive understanding of Java interrupts, you may mistakenly assume that the interrupted thread will immediately quit running, but that is not the case. How does the interrupt mechanism work? After the interrupt is captured or detected, what is the consequence of throwing a interruptedexception or resetting the interrupt state and swallowing the interrupt state in the method? What are the similarities and differences between thread.stop and interruptions? Under what circumstances do I need to use interrupts? This article will be described from several aspects.

2. Principle of interruption

The Java interrupt mechanism is a collaborative mechanism that means that interrupts do not terminate directly from another thread, and that threads that need to be interrupted handle interrupts themselves. This is like home parents told children to pay attention to the body, but whether the children pay attention to the body, how to pay attention to the body depends entirely on their own.

The Java interrupt model is also so simple that each thread object has a Boolean identifier (not necessarily the field of the thread class, and indeed not, these methods are ultimately done through the native method), representing whether there is an interrupt request (the request can come from All threads, including the interrupted thread itself. For example, when a thread T1 to the thread T2, you only need to set the interrupt identity of the threading T2 object to True in thread T1, and 2 can choose to handle the interrupt request at the right time, even ignoring the request, as if the thread had not been interrupted.

The Java.lang.Thread class provides several ways to manipulate this interrupt state, including:

public static Boolean interrupted	Test if the thread has been interrupted. The interrupt state of the thread is cleared by the method. In other words, if the method is called twice in a row, the second call returns FALSE, except if the first call has cleared its break state, and the second call is interrupted before the interrupt state is checked out.
public boolean isinterrupted()	Whether the test thread has been interrupted. The interrupt state of a thread is not affected by this method.
public void Interrupt()	The thread is disconnected.

Where the interrupt method is the only way to set the interrupt state to true. The static method interrupted the current thread's interrupt state, but the method's naming is highly intuitive and easily misleading, requiring special attention.

In the above example, the thread T1 the interrupt state of the thread T2 to TRUE,T2 by calling the interrupt method, which can be invoked at the appropriate time interrupted or isinterrupted to detect the state and do the appropriate processing.

In addition, the methods of some classes in the class library may call interrupts, such as the Cancel method in Futuretask, and if the passed argument is true, it will call the interrupt method on the thread that is running the asynchronous task, if the asynchronous task being executed If the code in is not responding to the interrupt, the parameters in the Cancel method will not be effective, and the Shutdownnow method in Threadpoolexecutor will traverse the worker thread in the thread pool and invoke the thread's interrupt method to break through. So if the task being performed in the worker thread does not respond to the interrupt, the task will continue until the normal end.

3. Interruption of processing

Since the Java interrupt mechanism simply sets the interrupt state of the interrupted thread, what does the interrupted thread do?

Processing time

Obviously, as a collaborative mechanism, the interrupted thread is not forced to be processed at a certain point. In fact, the interrupted thread only needs to be handled at the right time, if there is no proper point of view, or even if it is not handled, at the task-handling level, just like without calling the interrupt method. The "Right time" is closely related to the business logic of the line one thread in processing, for example, each iteration is preceded by a method that may be blocked and cannot be interrupted, but most often does not occur when a critical section updates another object's state, as this can cause the object to be in an inconsistent state.

The processing time determines the efficiency of the program and the sensitivity of the interrupt response. Frequent checking of interrupt status may cause program execution to degrade, and conversely, fewer checks may make interrupting requests less responsive. If the interrupted thread continues to perform a period of time without causing a disaster to the system after the interrupt request is issued, the interrupt processing can be placed where it is convenient to check for interruptions while at the same time ensuring a certain degree of responsiveness. When the performance index of the program is more critical, it may be necessary to set up a test model to analyze the best interrupt detection point to balance performance and response sensitivity.