Lesson6:java Thread Interrupt

Under normal circumstances, the business system will not interrupt its thread, but due to some special circumstances, the thread has not ended properly, and such a thread has affected the business system to provide service capabilities, if the system is designed to be robust, it will be monitored threads to actively interrupt such threads. However, if you randomly go to the thread, it is very dangerous, because the thread will occupy resources and change the content of variables, the best way is to send the interrupt signal to the threads, by the thread itself to interrupt themselves.

Source Address: Https://github.com/mantuliu/javaAdvance

First, let's analyze the source code with demo, Stop () and suspend () method problems:

     Public Final voidStop () {Stop (NewThreaddeath ()); }     Public Final synchronized voidStop (Throwable obj) {//Note the synchronous identity is used hereif(obj = =NULL)            Throw NewNullPointerException (); SecurityManager Security=System.getsecuritymanager (); if(Security! =NULL) {checkAccess (); if(( This! = Thread.CurrentThread ()) | |                (! (objinstanceofThreaddeath)))             {security.checkpermission (securityconstants.stop_thread_permission); }        }        //A Zero status value corresponds to "NEW", the It can ' t change to//Not-new because we hold the lock.        if(Threadstatus! = 0) {resume ();//Wake up thread if it is suspended; no-op otherwise if the thread is suspended and there is a wake-up operation, a deadlock may occur        }        //The VM can handle all thread statesstop0 (obj);//Stop thread, no recovery of used variable state}

Looking at the above code, there is a 3 deduction: 1.stop () thread because it is out of the external, for the business use of variables not to restore its state; the 2.stop () method does not throw an exception, The user did not get a warning 3. If the thread object itself is locked and has not been released, such as calling the Suspend () method, then this thread cannot be stopped by the Stop () method;

The demo Class Lesson6threadstoplock has shown conclusions 1 and 2;

The demo Class Lesson6threadstopdeadlock shows the conclusion 3 and proves that the Suspend method is prone to deadlock because it does not release any lock resources associated with the thread.

Since we can not use the Stop () method to go to the thread break, we should use what method, at the beginning of this article we mentioned to send the interrupt signal to the target thread, it interrupts itself, this interrupt instruction is the interrupt () method, in the thread-related many methods and keywords, Some are not responding to interrupts, such as the Lock () method of the lock class, the awaituninterruptibly () method of the condition class, the Synchronized keyword, and so on.

The demo Class Lesson6interruptsync shows that the synchronized does not respond to interrupts;

The demo Class Lesson6interruptlock shows that the lockinterruptibly () method can respond to interrupts and throw java.lang.InterruptedException exceptions;

Lesson6:java Thread Interrupt