We know that methods such as Stop and suspend to interrupt or block threads have been marked with the “@Deprecated” label in higher Java versions. So why have they been on the stage of Java history and gradually pushed out of the stage? Are they human distortion or moral decay? Or have they been replaced, and if so, by whom? Here we find out.

One, stop the curtain

Forces the thread to stop executing. Forces a thread to stop executing a executing executing executing executing executing a executing thread. So let’s take a look at how Java developers explain the death of Stop:We can see the following:

2. Stopping a Thread with Thread.stop causes it to unlock all locked monitors, which releases all locks that the current Thread has acquired, putting the current Thread directly into the blocking state

Let’s take two examples from above:

public static void main(String[] args) throws InterruptedException { Object o1=new Object(); Object o2=new Object(); Thread t1=new Thread(()->{synchronized (o1) {synchronized (o2) {try {system.out.println ("t1 obtain lock "); Thread.sleep(5000); System. The out. Println (" end of the t1 "); } catch (InterruptedException e) { e.printStackTrace(); }}}}); t1.start(); Thread.sleep(1000); Thread t2=new Thread(()->{synchronized (o1) {synchronized (o2) {try {system.out.println ("t2 obtain lock "); Thread.sleep(5000); System. The out. Println (" t2 end "); } catch (InterruptedException e) { e.printStackTrace(); }}}}); t2.start(); t1.stop(); }Copy the code

Running results:As you can see, when a thread t1 in acquiring the implementation to o1 and o2 two locks, in has not yet been the end of the execution, the main thread calls the stop method of t1 interrupt execution of the t1, the release of the t1 threads access to all the locks, capturing the interruption after t2 o1 and o2 lock, start till the end, and the t1 is died in the sleep, The code after sleep is not executed.

If the code after sleep is important code such as resource release or important business logic, or if other threads depend on the running result of T1 thread, the direct interruption may cause serious consequences.

Instead of using stop to interrupt a thread, we can find a solution in the Java developer’s comments:As you can see, the Java developers recommend using the following two methods to gracefully stop threads:

1. Define a variable and let the target thread continuously check the state of the variable and stop the thread when the variable reaches a certain state.

Code examples are as follows:

volatile static boolean flag=false; public static void main(String[] args) throws InterruptedException { Object o1=new Object(); Thread t1=new Thread(()->{synchronized (o1) {try {system.out.println ("t1 obtain lock "); while (! flag) Thread.sleep(5000); // Execute the business logic system.out.println ("t1 end "); } catch (InterruptedException e) { e.printStackTrace(); }}}); t1.start(); Thread.sleep(1000); Threadt2 =new Thread(()->{synchronized (o1) {try {system.out.println ("t2 obtain lock "); Thread.sleep(5000); // Execute the business logic system.out.println ("t2 end "); } catch (InterruptedException e) { e.printStackTrace(); }}}); t2.start(); flag=true; }Copy the code

Running results: 2. Use the interrupt method to interrupt a thread.

Code examples are as follows:

public static void main(String[] args) throws InterruptedException { Object o1=new Object(); Threadt1 =new Thread(()->{synchronized (o1) {system.out.println ("t1 obtain lock "); while (! Thread.currentThread().isInterrupted()) { for (int i = 0; i < 100; i++) { if(i==50) System.out.println(); System.out.print(i+" "); } System.out.println(); } system.out.println ("t1 end "); }}); t1.start(); Threadt2 =new Thread(()->{synchronized (o1) {try {system.out.println ("t2 obtain lock "); Thread.sleep(5000); // Execute the business logic system.out.println ("t2 end "); } catch (InterruptedException e) { e.printStackTrace(); }}}); t2.start(); t1.interrupt(); }Copy the code

Running results:We use while (! Thread.currentthread ().isinterrupted ()) checks whether the currentThread has been interrupted, in which case the Thread dies naturally and the lock is released. As you can see, calling an interrupt method does not interrupt a thread as violently as a stop method. It waits until the current running logic ends before checking for interruption, which is very elegant.

Note: The run example code may not print a number because the T1 thread runs into while(! If thread.currentthread ().isinterrupted ()) isInterrupted, the main Thread already has the interrupt method, so multiple runs may print a number.

The end of suspend

The suspend method suspends a thread until the resume method is called to resume it. However, the suspend method does not release the lock acquired by the suspended thread. Both sides are therefore labeled deadlocked-prone. This, of course, is what led to the end of Suspend and Resume. Similarly, let’s look at the reasons Java developers have given for suspending suspend:From this we can draw the following conclusions:

Suspend has a natural deadlock tendency. After suspend, the locks held by the thread are not released and other threads cannot access the resources. 3. The lock cannot be released, resulting in a deadlock

Next simulate a deadlock scenario caused by suspend, Talk is cheap,show my code:

public static void main(String[] args) throws InterruptedException { Object o1=new Object(); Object o2=new Object(); Threadt1 =new Thread(()->{synchronized (o1) {system.out.println ("t1 obtains o1 "); try { Thread.sleep(5000); } catch (InterruptedException e) {e.printStackTrace(); } system.out. println("t1 end of execution "); }}); t1.start(); Threadt2 =new Thread(()->{synchronized (o2) {system.out.println ("t2 "); try { Thread.sleep(2000); } catch (InterruptedException e) {e.printStackTrace(); } synchronized (o1) {system.out.println ("t2 obtain o1 lock and continue "); } system.out. println("t2 end of execution "); }}); t2.start(); Thread.sleep(1000); t1.suspend(); // Suppose an unknown exception is thrown int I =1/0; t1.resume(); }Copy the code

Running results:T1 is suspended and cannot release o1 lock. T2 needs to acquire o1 lock to continue execution, but it has to wait for T1 to hold o1 lock. From now on the whole program fell into an endless wait —- deadlock.

Author: wave after blog.csdn.net/qq_40400960/article/details/112651249