浏览 7820 次
锁定老帖子 主题:线程任务的取消
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-09-03
java 代码
main中启动一个素数生成的任务,线程运行一秒就取消掉。通过线程中的cancelled变量来表征任务是否继续执行。既然是最简单的策略,那么什么是 例外情况?显然,阻塞操作下(比如调用join,wait,sleep方法),这样的策略会出问题。任务因为调用这些阻塞方法而被阻塞,它将不会去检查 volatile变量,导致取消操作失效。那么解决办法是什么?中断!考虑我们用BlockingQueue去保存生成的素数, BlockingQueue的put方法是阻塞的(当BlockingQueue满的时候,put操作会阻塞直到有元素被take),让我们看看不采用中 断,仍然采用简单策略会出现什么情况: java 代码
我们在main中通过queue.take来消费产生的素数(虽然仅仅是取出扔掉),我们只消费了1000个素数,然后尝试取消产生素数的任务,很遗憾, 取消不了,因为产生素数的线程产生素数的速度大于我们消费的速度,我们在消费1000后就停止消费了,那么任务将被queue的put方法阻塞,永远也不 会去判断cancelled状态变量,任务取消不了。正确的做法应当是使用中断(interrupt): java 代码
在run方法中,通过Thread的isInterrupted来判断interrupt status是否已经被修改,从而正确实现了任务的取消。关于interrupt,有一点需要特别说明,调用interrupt并不意味着必然停止目标线 程的正在进行的工作,它仅仅是传递一个请求中断的信号给目标线程,目标线程会在下一个方便的时刻中断。而对于阻塞方法产生的 InterruptedException的处理,两种选择:要么重新抛出让上层代码来处理,要么在catch块中调用Thread的interrupt 来保存中断状态。除非你确定要让工作线程终止(如上所示代码),否则不要仅仅是catch而不做任务处理工作(生吞了 InterruptedException),更详细可以参考这里。如果不清楚外部线程的中断策略,生搬硬套地调用interrupt可能产生不可预料的后果,可参见书中7.1.4例子。 另外一个取消任务的方法就是采用Future来管理任务,这是JDK5引入的,用于管理任务的生命周期,处理异常等。比如调用ExecutorService的sumit方法会返回一个Future来描述任务,而Future有一个cancel方法用于取消任务。 那么,如果任务调用了不可中断的阻塞方法,比如Socket的read、write方法,java.nio中的同步I/O,那么该怎么处理呢?简单地,关闭它们!参考下面的例子: java 代码
Reader线程重写了interrupt方法,其中调用了socket的close方法用于中断read方法,最后,又调用了super.interrupt(),防止当调用可中断的阻塞方法时不能正常中断。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-09-04
这个里面如果子线程里面在接收到中断后(interrupt status被改变),如果一直没有阻塞方法 此任务是不是会一直执行下去呢?
也就是说这个"下一个方便的时刻"是不是就是指阻塞方法被调用时呢? 在run方法中,通过Thread的isInterrupted来判断interrupt status是否已经被修改,从而正确实现了任务的取消。关于interrupt,有一点需要特别说明,调用interrupt并不意味着必然停止目标线 程的正在进行的工作,它仅仅是传递一个请求中断的信号给目标线程,目标线程会在下一个方便的时刻中断。而对于阻塞方法产生的 InterruptedException的处理,两种选择:要么重新抛出让上层代码来处理,要么在catch块中调用Thread的interrupt 来保存中断状态。除非你确定要让工作线程终止(如上所示代码),否则不要仅仅是catch而不做任务处理工作(生吞了 InterruptedException),更详细可以参考这里。如果不清楚外部线程的中断策略,生搬硬套地调用interrupt可能产生不可预料的后果,可参见书中7.1.4例子。 |
|
返回顶楼 | |
发表时间:2007-09-05
调用阻塞方法(join,wait,sleep),那么当收到中断信号,会抛出InterruptedException,离开阻塞状态;而如果没有调用 这些阻塞方法,中断信号将可以被忽略,当然你可以通过Thread.currentThread().isInterrupted()判断状态来进行手工 处理。
|
|
返回顶楼 | |
发表时间:2007-09-05
我前两天解决过这个问题,给你写了解决办法,结果被可笑的弄成灌水帖子,这个问题我研究了3天才弄明白.你自己在我博客上找吧,有个StreamGobbler的方法,用那个就不会无限 waitFor()再次bs下javaeye.还有有问题可以去javaworld上问我现在一般都去那里了.这里已经走上歧途
|
|
返回顶楼 | |
发表时间:2008-02-03
hellsing42 写道 我前两天解决过这个问题,给你写了解决办法,结果被可笑的弄成灌水帖子,这个问题我研究了3天才弄明白.你自己在我博客上找吧,有个StreamGobbler的方法,用那个就不会无限 waitFor()再次bs下javaeye.还有有问题可以去javaworld上问我现在一般都去那里了.这里已经走上歧途
看来大家的见解基本相同啊。 |
|
返回顶楼 | |
发表时间:2008-02-03
文章写的很不错,线程可中断实现是非常麻烦的事情,通过volatile标志和中断都可能有问题。java concurrent practice 和 java 多线程设计模式都有讲解,其中比较赞同volatile和interrupt中断同时应用来保证cancel成功。
其他的关于有人评灌水有些时候是很讨厌的事情,真的怀疑投票得人弄清楚问题是什么没有。 |
|
返回顶楼 | |
发表时间:2008-02-17
代码有问题,第二个类BrokenPrimeProducer的cancel方法里应该改为:
this.cancelled = true;线程BrokenPrimeProducer会去判断cancelled状态变量的 |
|
返回顶楼 | |