A thread shoud not be controlled directly by other threads

目录

1.Deprecated methods

2.suspend() & resume()

3.destroy()

4.stop()

---

1.Deprecated methods

In mulitple-thread application, threads may communicate with each other to share(write, read or lock) common memory. But any thread usually shoudn't directly make other thread suspended ,stopped or destroyed, though the ability is provided with instance method suspend(), resume(), stop() and destroy() in class Thread.

In java api document, such method suspend(), resume(), destroy() and stop() are deprecated. Let's check out the following examples to find out why.

 

2.suspend() & resume()

public class Suspend {
    
    public static Object lock = new Object();  
    
    public static class CalculateTaskThread extends Thread{        
        @Override
        public void run() {            
            synchronized (lock) {                
                // ... do calculate task, will cost 20 seconds
                Thread.sleep(20 * 1000);
            }
        }
    }
    
    public static void main(String[] args) {
        
        Thread calculateTaskThread = new CalculateTaskThread();
        calculateTaskThread.start();
        
        // sleep 10 senconds to wait calculateTaskThread to run.
        Thread.sleep(10 * 1000);
        
        // suspend calculateTaskThread
        calculateTaskThread.suspend();
        
        // aquire lock to do something
        synchronized (lock) {            
            // do something
        }        
        // resume calculateTaskThread
        calculateTaskThread.resume();
    }
}

In the java example aboved, there are two threads: calculateTaskThread and main thread, when calculateTaskThread starts and executes calculate task, main thread invoke suspend() to suspend calculateTaskThread, then main thread want to aquire to do something, but calculateTaskThread are holding the lock while being suspended, so main thread can not aquire lock and keep waitting. That causes two threads are waitting indefinitely, also called dead-lock.

 

Tips: If your application had severe dead-lock problem, you can use jstack tool provided by jdk to analyse thread with informations about thread state, monitor lock and etc. For example , I ran the codes above in my portable computer, then I use jstack to print informations of threads that have started.

From the informations printed in console, we can see that main thread are blocked waiting to lock object with address number <0x00000000d6e34bf8>, but such obejct <0x00000000d6e34bf8> is locked by calculateTask and calculateTask is in TIME_WAITING, so main thread will not get lock.

There is the other reason for deprecating suspend(), resume(), let's see codes written as follows.

public class Suspend {
    
    public static Object lock = new Object();    
    
    public static class CalculateTaskThread extends Thread{
        
        @Override
        public void run() {            
            synchronized (lock) {                
                // suspend itself
                suspend();
            }
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        
        Thread calculateTaskThread = new CalculateTaskThread();        
        
        synchronized (lock) {            
            calculateTaskThread.start();
            
            // sleep 10 senconds to wait calculateTaskThread to run.
            Thread.sleep(10 * 1000);
            
            // resume calculateTaskThread
            calculateTaskThread.resume();
        }
    }
}

In the example above, main thread holds lock and starts calculateTaskThread, then the calculateTaskThread starts to run and wait for aquiring lock to suspend itself, but then main thread resume calculateTaskThread before calculateTaskThread actually suspends itself, so the resume action doesn't work. When the main thread exits to return lock to calculateTaskThread, calculateTaskThread will suspend itself forever. Call order between suspend() and resume() must be strict avoiding terrible result.

 

3.destroy()

This method was never implemented. It was original designed to detroy this thread without any cleanup. Any monitors it held would have remained lock. it woud be deadlock-prone in much the manner of suspend(). If the target thread held a lock protecting a critical system resources when it was detroyed, no thread could ever access the resources again. If another thread ever attempt to lock this resource, deadlock would result.

 

4.stop()

stop() causes the thread to unlock all monitors that it has held, If any of the objects previously protected by these monitors were in a inconsistent state, these damaged objects would become visible to other threads, potentially result in arbitrary behavior.

本文地址：https://blog.csdn.net/Turnhead/article/details/109645075