为什么需要线程的取消机制？
开启一个线程很容易。绝大多数时间，我们都会让它们自己运行直到结束。
但有时，我们希望提前结束线程。
哪些情况会需要提前结束呢？
用户请求取消
用户点击前端的“取消”按钮或接口调用发出取消请求（例如JMX）
有时间限制的操作
比如，某应用需要在有限时间内搜索问题空间，并在这个时间内选择最佳的解决方案。当计时器超时时，需要取消所有正在搜索的任务
应用程序事件
例如，应用程序对某个问题空间进行分解并搜索，从而使不同的任务可以搜索问题空间中的不同区域。当其中一一个任务找到了解决方案时，所有其他仍在搜索的任务都将被取消
错误
网页爬虫程序搜索相关的页面，并将页面或摘要数据保存到硬盘。当一个爬虫任务
发生错误时(例如，磁盘空间已满)，那么所有搜索任务都会取消，此时可能会记录它们的当前状态，以便稍后重新启动
关闭
当一个程序或服务关闭时，必须对正在处理和等待处理的工作执行某种操作。在平
缓的关闭过程中，当前正在执行的任务将继续执行直到完成，而在立即关闭过程中，当前的任务则可能取消。
在Java中没有安全的抢占式方法停止线程，只有一些协作式的机制，使请求取消的任务和代码都遵循一种既定协议。
其中一种协作机制能设置某个“已请求取消(Cancellation Requested)” 标志，而任务将定
期地查看该标志。如果设置了这个标志，那么任务将提前结束。
要使任务和线程能安全、快速、可靠地停止下来，并非易事。Java 没有提供任何机制来安全地终止线程。
曾经的 Thread.stop 和 suspend 问题很大，禁止使用！
但Java提供了中断(Interruption)， 这是一种协作机制，能够使一个线程终止另一个线程的当前工作。
这种协作应用场景是很多的，我们其实很少会希望某个任务、线程或服务立即停止，因为这种立即停止会使共享的数据结构处于不一致状态。
在编写任务和服务时可以使用这样的协作：当需要停止时，首先会清除当前正在执行的工作，然后再结束。这提供了更好的灵活性，因为任务本身的代码比发出取消请求的代码更清楚如何执行清理工作。
生命周期结束(End-of-Lifecycle) 的问题会使任务、服务以及程序的设计和实现等过程变
得复杂，而这个在程序设计中非常重要的要素却经常被忽略。
行为良好的软件与勉强运行的软件之间的最主要区别就是，行为良好的软件能很完善地处理失败、关闭和取消等过程。
有哪些任务取消的方案呢？
其实一种就是“标记位”。例如使用volatile类型的域保存取消状态标识。
代码如下：
一个可取消的任务必须有取消策略(CancellationPolicy)，在这个策略中将详细定义：
其他代码如何(How)请求取消该任务
任务在何时(When)检查是否已经请求了取消
在响应取消请求时应该执行哪些(What) 操作
考虑现实世界中停止支付(Stop-Payment) 支票的示例。银行通常都会规定如何提交一个
停止支付的请求，在处理这些请求时需要做出哪些响应性保证，以及当支付中断后需要遵守哪些流程(例如通知该事务中涉及的其他银行，以及对付款人的账户进行费用评估)。这些流程和保证放在一起就构成了支票支付的取消策略。
PrimeGenerator使用了一种简单的取消策略：客户代码通过调用cancel来请求取消，
PrimeGenerator在每次搜索素数前首先检查是否存在取消请求，若存在则退出。
