为什么不能使用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