【多线程_提高篇】 thread.stop禁用的原因

为什么不能使用Thread.stop()方法？

从SUN的官方文档可以得知，调用Thread.stop()方法是不安全的，这是因为当调用Thread.stop()方法时，会发生下面两件事：

1. 即刻抛出ThreadDeath异常，在线程的run()方法内，任何一点都有可能抛出ThreadDeath Error，包括在catch或finally语句中。

2. 释放该线程所持有的所有的锁

 

当线程抛出ThreadDeath异常时，会导致该线程的run()方法突然返回来达到停止该线程的目的。ThreadDetath异常可以在该线程run()方法的任意一个执行点抛出。但是，线程的stop()方法一经调用线程的run()方法就会即刻返回吗？

public class stopTest {
    public static void main(String[] args) {  
        try {  
            Thread t = new Thread() {  
                public synchronized void run() {  
                    try {  
                        long start=System.currentTimeMillis();  
                        for (int i = 0; i < 100000; i++)  
                            System.out.println("runing.." + i);  
                        System.out.println((System.currentTimeMillis()-start)/1000);  
                    } catch (Throwable ex) {  
                        System.out.println("Caught in run: " + ex);  
                        ex.printStackTrace();  
                    }  
                }  
            };  
            t.start();  
            // Give t time to get going...  
            Thread.sleep(100);  
            t.stop(); // EXPECT COMPILER WARNING  
        } catch (Throwable t) {  
            System.out.println("Caught in main: " + t);  
            t.printStackTrace();  
        }  
  
    }  
}

假设我们有如上一个工作线程，它的工作是数数，从1到1000000，我们的目标是在它进行数数的过程中，停止该线程的运作。如果我们按照上面的方式来调用thread.stop()方法，原则上是可以实现我们的目标的，根据SUN官方文档的解释，加上在上面的程序中，主线程只休眠了100ms，而工作线程从1数到1000000所花时间大概是4-5s，那么该工作线程应该只从1数到某个值（小于1000000），然后线程停止。 

 

但是根据运行结果来看，并非如此。

 

结果：

runing..99985
runing..99986
runing..99987
runing..99988
runing..99989
runing..99990
runing..99991
runing..99992
runing..99993
runing..99994
runing..99995
runing..99996
runing..99997
runing..99998
runing..99999
1

每次运行的结果都表明，工作线程并没有停止，而是每次都成功的数完数，然后正常中止，而不是由stop()方法进行终止的。这个是为什么呢？根据SUN的文档，原则上只要一调用thread.stop()方法，那么线程就会立即停止，并抛出ThreadDeath error，查看了Thread的源代码后才发现，原先Thread.stop0()方法是同步的，而我们工作线程的run()方法也是同步，那么这样会导致主线程和工作线程共同争用同一个锁（工作线程对象本身），由于工作线程在启动后就先获得了锁，所以无论如何，当主线程在调用t.stop()时，它必须要等到工作线程的run()方法执行结束后才能进行，结果导致了上述奇怪的现象。

 

把上述工作线程的run()方法的同步去掉，再进行执行，结果就如上述第一点描述的那样了

 

可能的结果：

runing..17009
runing..17010
runing..17011
runing..17012
runing..17013
runing..17014
runing..17015
runing..17016
runing..17017
runing..17018
runing..17019runing..17019Caught in run: java.lang.ThreadDeath
java.lang.ThreadDeath
	at java.lang.Thread.stop(Thread.java:715)
	at com.mz.stop.stopTest.main(stopTest.java:22)

    public static void main(String[] args) {  
            final Object lock = new Object();  
            try {  
                Thread t0 = new Thread() {  
                    public void run() {  
                        try {  
                            synchronized (lock) {  
                                System.out.println("thread->" + getName()  
                                        + " acquire lock.");  
                                sleep(3000);// sleep for 3s  
                                System.out.println("thread->" + getName()  
                                        + " release lock.");  
                            }  
                        } catch (Throwable ex) {  
                            System.out.println("Caught in run: " + ex);  
                            ex.printStackTrace();  
                        }  
                    }  
                };  
      
                Thread t1 = new Thread() {  
                    public void run() {  
                        synchronized (lock) {  
                            System.out.println("thread->" + getName()  
                                    + " acquire lock.");  
                        }  
                    }  
                };  
      
                t0.start();  
                // Give t time to get going...  
                Thread.sleep(100);  
                //t0.stop();  
                t1.start();  
            } catch (Throwable t) {  
                System.out.println("Caught in main: " + t);  
                t.printStackTrace();  
            }  
      
        }  

当没有进行t0.stop()方法的调用时， 可以发现，两个线程争用锁的顺序是固定的。

 

输出：

thread->Thread-0 acquire lock.
thread->Thread-0 release lock.
thread->Thread-1 acquire lock.

 

但调用了t0.stop()方法后，（去掉上面的注释//t0.stop();），可以发现，t0线程抛出了ThreadDeath error并且t0线程释放了它所占有的锁。

 

输出：

thread->Thread-0 acquire lock.
thread->Thread-1 acquire lock.
Caught in run: java.lang.ThreadDeath
java.lang.ThreadDeath
 at java.lang.Thread.stop(Thread.java:715)
 at com.yezi.test.timeout.ThreadStopTest.main(ThreadStopTest.java:40)

 

 

从上面的程序验证结果来看，thread.stop()确实是不安全的。它的不安全主要是针对于第二点：释放该线程所持有的所有的锁。一般任何进行加锁的代码块，都是为了保护数据的一致性，如果在调用thread.stop()后导致了该线程所持有的所有锁的突然释放，那么被保护数据就有可能呈现不一致性，其他线程在使用这些被破坏的数据时，有可能导致一些很奇怪的应用程序错误。

举个例子：

如果线程当前正持有锁，stop之后则会释放该锁。由于此错误可能出现在很多地方，那么这就让编程人员防不胜防，极易造成对象状态的不一致。例如，对象obj中存放着一个范围值：最小值low，最大值high，且low不得大于high，这种关系由锁lock保护，以避免并发时产生竞态条件而导致该关系失效。假设当前low值是5，high值是10，当线程t获取lock后，将low值更新为了15，此时被stop了，真是糟糕，如果没有捕获住stop导致的Error，low的值就为15，high还是10，这导致它们之间的小于关系得不到保证，也就是对象状态被破坏了！如果在给low赋值的时候catch住stop导致的Error则可能使后面high变量的赋值继续，但是谁也不知道Error会在哪条语句抛出，如果对象状态之间的关系更复杂呢？这种方式几乎是无法维护的，太复杂了！如果是中断操作，它决计不会在执行low赋值的时候抛出错误，这样程序对于对象状态一致性就是可控的。

正是因为可能导致对象状态不一致，stop才被禁用。

如何正确停止线程

关于如何正确停止线程，这篇文章(how to stop thread)给出了一个很好的答案, 总结起来就下面3点（在停止线程时）：

1. 使用violate boolean变量来标识线程是否停止

2. 停止线程时，需要调用停止线程的interrupt()方法，因为线程有可能在wait()或sleep(), 提高停止线程的即时性

3. 对于blocking IO的处理，尽量使用InterruptibleChannel来代替blocking IO