《java并发编程实战》笔记（第7章）

java没有提供任何机制来安全的终止线程，但是提供了中断（Interruption）,这是一种协作机制，能够使一个线程终止另一个线程的当前工作。
这种协作机制的方法是必要的，我们很少希望某个任务，线程或服务立即停止，因为这种立即停止会使共享的数据结构处于不一致的状态。相反，在编写任务和服务时可以使用一种协作的方式：当需要停止时，它们首先会清除当前正在执行的工作，然后再结束。这提供了更好的灵活性，因为任务本身的代码比发出取消请求的代码更清楚如何执行清除工作。

* 取消某个操作的原因：

      1.用户请求取消。
      2.有时间限制的操作。
      3.应用程序事件
      4.错误
      5.关闭。

 一个可取消的任务必须拥有取消策略，在这个策略中将详细地定义取消操作的“how”,"when"以及“what”,即其他代码如何请求取消该任务，任务在何时检查是否已经请求了取消，以及在相应取消请求时应该执行哪些操作。

 public class Thread{
      public void interrupt(){}     //中断目标线程
      public boolean isInterrupted(){}     //返回目标线程的中断状态
      public static boolean interrupted(){}     //清除当前线程的中断状态，并返回它之前的值，这也是清除中断状态的唯一方法。
 }
 当中断线程时，这个线程的中断状态将被设置为true.


 调用interrupt并不意味着立即停止目标线程正在进行的工作，而只是传递了请求中断的消息。
 对中断操作的正确理解是：它并不会真正地中断一个正在运行的线程，而只是发出中断请求，然后由线程在下一个合适的时刻中断自己。（这些时刻也被称为取消点）
 通常，中断是实现取消的最合理方式

 在使用静态的interrupted时应该小心，因为它会清除当前线程的中断状态！如果在调用interrupted时返回了true，那么除非你想屏蔽这个中断，否则必须对它进行处理——可以抛出InterruptedException，或者通过再次调用interrupt来恢复中断状态。

 最合理的终端策略是某种形式的线程级（Thread-Level）取消操作或服务级（Service-Level）取消操作：尽快退出，在必要时进行清理，通知某个所有者该线程已经退出。此外还可以建立其他的中断策略，例如暂停服务或重新开始服务。

 由于每个线程拥有各自的中断策略，因此除非你知道中断对该线程的含义，否则就不应该中断这个线程。

 当调用可中断的阻塞函数时，例如Thread.sleep 或 BlockingQueue.put等，有两种实用策略可用于处理InterruptedException:
 1.传递异常，从而使你的方法也成为可中断的阻塞方法
 2.恢复中断状态，从而使调用栈中的上层代码能够对其进行处理。（通过再次调用interrupt来恢复中断状态）

 Future.cancel

boolean cancel(boolean mayInterruptIfRunning)
试图取消对此任务的执行。
在什么情况下调用cancel可以将参数指定为true ？？？
解答：执行任务的线程是由标准的Executor创建的，它实现了一种中断策略使得任务可以通过中断被取消，所以如果任务在标准Executor中运行，并通过它们的Future来取消任务，那么可以设置mayInterruptIfRunning。如果mayInterruptIfRunning为true并且任务当前正在某个线程中运行，那么这个线程能被中断。如果这个参数为false,那么意味着“若任务还没有启动，就不要运行它”，这种方式应该用于那些不处理中断的任务中。

 当Future.get抛出InterruptedException或TimeoutException，如果你知道不再需要结果，那么就可以调用Future.cancel来取消任务。