Dealing with InterruptedException

最近重新温习了一下Java多线程，发现对于Thread.interrupt()机制还是不太理解。在论坛里面找了找相关的帖子，看到一个链接，发现里面写的非常好。

 

简单的翻译一下，一个加深自己的理解，另一个也想跟感兴趣的同学共享交流一下（之前相关工作从事的不多，再加上语言能力有限，可能有些语言翻译的比较晦涩，也请同学们帮忙指正）。

原帖地址如下：http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

由于我更关心interrupt机制，这里先翻译Thread interruption这一段，将来有时间一定返回来全部译完，请大家见谅。

线程中断

    Java中，每一个线程都包含一个布尔型变量，用来表示该线程中断状态，默认设置为false。当一个线程被其他（一个/几个）线程通过Thread.interrupt()方法设置为中断状态时，会发生以下两种情况：如果这个线程正在执行一个底层可中断的方法，例如：sleep(),join()或者wait()等，并不会引起该线程阻塞，而是直接抛出一个InterruptionException。如果不是上述情况，interrupt()方法仅仅只是改变了线程包含的interrupt status的状态。线程会在接下来的执行中轮询该状态来判断是否需要终止线程。这个状态可以被Thread实例方法isInterrupted()查询，同样的也可以被Thread类的静态方法interrupted()查询，需要注意的是，Thread.interrupted()方法在查询的同时会修改该线程对应的status的值。

       （上面这一段话与core java中提到的一样，我个人认为重点在后面第二段话的解释。）

    线程中断采用协作机制。这意味着，当某个线程尝试中断其他线程，被中断线程并不会马上停止当前工

作。相反的，中断机制只是友好的发送一个其他线程在适当时候中断当前操作的请求。某些JDK提供的方法，例如sleep()，十分看重这个请求，不过其他大部分方法并不理睬，这些方法不仅不会阻塞，甚至有可能继续运行相当长一段时间才能在线程再次轮询中断状态时注意到这个请求并提前返回。所以你可以随意忽视任一中断请求，当然这样有可能会影响线程对于中断的响应。

    这样做的一个好处就是我们可以更加灵活的创建安全的可取消（中断）的动作。现实开发中，我们不太希望一个线程中的活动被立刻终止，如果这样做（立即中断），程序有可能在保存的数据更新尚未完成时被中断，导致数据结构的不一致状态。中断机制允许线程保留一个取消动作用来清楚之前的工作成果，还原变量，提醒其他操作，最后结束线程工作。