现在的位置: 首页 > 综合 > 正文

如何正确停止java中的线程

2013年10月29日 ⁄ 综合 ⁄ 共 6118字 ⁄ 字号 评论关闭

 

 

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

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

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

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

 

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

 

 

Java代码
复制代码
 收藏代码
  1. public static void main(String[] args) {   
  2.         try {   
  3.             Thread t = new Thread() {   
  4.                 public synchronized void run() {   
  5.                     try {   
  6.                         long start=System.currentTimeMillis();   
  7.                         for (int i = 0; i < 100000; i++)
      
  8.                             System.out.println("runing.." + i);   
  9.                         System.out.println((System.currentTimeMillis()-start)/1000);   
  10.                     } catch (Throwable ex) {   
  11.                         System.out.println("Caught in run: " + ex);   
  12.                         ex.printStackTrace();   
  13.                     }   
  14.                 }   
  15.             };   
  16.             t.start();   
  17.             // Give t time to get going...
      
  18.             Thread.sleep(100);   
  19.             t.stop(); // EXPECT COMPILER WARNING
      
  20.         } catch (Throwable t) {   
  21.             System.out.println("Caught in main: " + t);   
  22.             t.printStackTrace();   
  23.         }   
  24.   
  25.     }  

 

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

 

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

 

结果:

。。。

 

runing..99998

runing..99999

5

 

 

。。。

 

runing..99998

runing..99999

4

 

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

 

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

 

可能的结果:

runing..4149
runing..4150
runing..4151
runing..4152runing..4152Caught in run: java.lang.ThreadDeath

 

或者

 

runing..5245
runing..5246
runing..5247
runing..5248runing..5248Caught in run: java.lang.ThreadDeath

 

 

 

接下来是看看当调用thread.stop()时,被停止的线程会不会释放其所持有的锁,看如下代码:

 

Java代码
复制代码
 收藏代码
  1. public static void main(String[] args) {   
  2.         final Object lock = new Object();   
  3.         try {   
  4.             Thread t0 = new Thread() {   
  5.                 public void run() {   
  6.                     try {   
  7.                         synchronized (lock) {   
  8.                             System.out.println("thread->" + getName()   
  9.                                     + " acquire lock.");   
  10.                             sleep(3000);// sleep for 3s
      
  11.                             System.out.println("thread->" + getName()   
  12.                                     + " release lock.");   
  13.                         }   
  14.                     } catch (Throwable ex) {   
  15.                         System.out.println("Caught in run: " + ex);   
  16.                         ex.printStackTrace();   
  17.                     }   
  18.                 }   
  19.             };   
  20.   
  21.             Thread t1 = new Thread() {   
  22.                 public void run() {   
  23.                     synchronized (lock) {   
  24.                         System.out.println("thread->" + getName()   
  25.                                 + " acquire lock.");   
  26.                     }   
  27.                 }   
  28.             };   
  29.   
  30.             t0.start();   
  31.             // Give t time to get going...
      
  32.             Thread.sleep(100);   
  33.             //t0.stop();   
  34.             t1.start();   
  35.         } catch (Throwable t) {   
  36.             System.out.println("Caught in main: " + t);   
  37.             t.printStackTrace();   
  38.         }   
  39.   
  40.     }  

 

 

当没有进行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()后导致了该线程所持有的所有锁的突然释放,那么被保护数据就有可能呈现不一致性,其他线程在使用这些被破坏的数据时,有可能导致一些很奇怪的应用程序错误。

 

 

 

如何正确停止线程

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

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

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

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

 

核心如下:

 

If you are writing your own small thread then you should follow the following example code.

    private volatile Thread myThread;
    public void stopMyThread() {
        Thread tmpThread = myThread;
        myThread = null;
        if (tmpThread != null) {
            tmpThread.interrupt();
        }
    }
    public void run() {
        if (myThread == null) {
           return; // stopped before started.
        }
        try {
            // all the run() method's code goes here
            ...
            // do some work
            Thread.yield(); // let another thread have some time perhaps to stop this one.
            if (Thread.currentThread().isInterrupted()) {
               throw new InterruptedException("Stopped by ifInterruptedStop()");
            }
            // do some more work
            ...
        } catch (Throwable t) {
           // log/handle all errors here
        }
    }

抱歉!评论已关闭.