【读后感】Java Concurrency in Practice：6.取消与关闭

0. kindle的屏幕好有意思呀

为了使任务和线程更加安全、快速、可靠地停止下来，因此Java没有提供任何机制来安全地终止线程，但它提供了中断机制，这是一种协作机制（因为任务本身地代码比发布取消请求的代码更清楚如何执行清除工作）。

其实 " 目标线程.interrupt() " 只是设置一个表达中断语义的标志位而已…

1. 任务取消

常见的取消操作的场景：

• 用户通过图形化界面，调用接口发出“取消请求”。
• 有限时间的操作:计时器超时、在有限时间内求最优解。
• 针对某个问题空间进行分解并搜索，当其中一个任务找到解决方案时，其他的任务都可以被取消。
• 错误：当爬虫程序发生错误(磁盘满了)，那么所有搜索任务都会被取消，并且记下当前状态，方便稍后重新启动。
• 服务关闭：略

1.1 中断

使用BQ的时候，如果生产速度超过消费速度，那么可能导致put被队列阻塞。这时候，调用其cancel()来设置cancelled标志，可能导致生产者永远无法检查到这个请求(因此消费者已经被中断了，那么put将永远被阻塞下去)。

有一些特殊的阻塞库的一些方法支持中断，例如Thread.sleep()、Object.wait()等，都会检查线程何时中断，并在发现中断时提前返回。它们响应中断的方式包括：清除中断状态、抛出InterruptException。JVM并不能保证阻塞方法检测到中断的速度，但实际上响应中断的速度还是非常快的。

当线程在非阻塞状态下中断时，它的中断状态将被设置，然后根据将被取消的操作来检查中断状态以判断发生了中断。通过这种方法，中断操作将变得“有黏性”——如果不触发InterruptException,那么中断状态并一直保持，直到明确地清楚中断状态。这也促成了interrupt()的调用不会立马中断目标线程，而是传递了取消执行的请求，直至目标线程准备好了再自我中断。

在Java的API或语言规范中，并没有将中断与任何取消语义关联起来，但实际上，如果在取消之外使用中断，那么都是不合适的，并且很难支撑起更大的应用。

粗略的扯一下中断策略的设计思路：
像sleep()、wait()、join()，当它们收到中断请求或者开始执行的时候发现某个已经设置好的中断状态时，将严格处理(抛出IE)。设计良好的方法只要能够使调用者的代码对中断进行处理，就可以完全忽略这种请求；设计糟糕的方法将直接屏蔽中断请求，导致调用栈上的其他方法无法对其做出响应。

可以通过while(xxx.isInterrupted())来提高中断的响应度。

1.2 中断策略

因为大多数任务都不会在自己拥有的线程中执行，而是在某个服务(例如：线程池)拥有的线程中执行，对于非线程所有者的代码来说，最合理的中断策略：尽快退出，在必要的时候进行清理，通知某个所有者该线程已经退出，尽快的通知调用栈的上层代码以使其可以采取响应措施。此外还有一些其他的策略：暂停服务、重启服务。

粗略的扯一下中断响应的思路：
除了抛出IE，还可以先捕获IE之后再恢复中断。

正如任务代码不应该对其执行所在线程的中断策略做出假设，执行取消操作的代码也不应该对线程的中断策略做出假设。线程应该只能由其所有者中断，所有者可以将线程的中断策略信息封装到某个合适的取消机制中，例如关闭(shutdown)方法。

---

延迟对中断的处理，可以使得开发人员能制定更灵活的中断策略，从而使应用程序在应用程序在响应性和健壮性之间实现合理的平衡。

try {
	interruptiblyMethod();
} catch (InterruptException ie) {
	// do someting ...(延迟处理)
	throw ie;
} finally {
	// do someting finally ...
}

1.3 响应中断

如果无法传递IE,那么可以通过再次调用interrupt()来恢复中断状态。

对于一些不支持取消但仍可以调用可中断阻塞方法的操作：
通过在循环调用这些方法，并在发现中断之后重试
先将中断状态保存到本地，并非在捕获IE时恢复中断状态，而是重试阻塞方法，最后在返回前恢复中断状态
过早的恢复中断状态，可能导致死循环，因为大多数可中断的阻塞方法都会在入口处检查中断状态，当接收到中断请求后立即抛出IE(毕竟尽快响应中断，可以尽早地通知调用栈上层代码，达到提高响应)

在取消过程中，可能涉及除中断状态以外的其他状态，可以为中断的线程提供进一步的指示：
例如，ThreadPoolExecutor拥有的工作线程检测到中断时，会检查线程池是否关闭。
如果是，则执行一些线程池的清理工作
否则，它可能会创建一个新线程将线程池恢复到合理的规模

1.4 计时运行

如果通过抛出一个未检查异常来表达超时，那么这样做是很容易被忽略(因为在任务执行线程，很容易因为不需要显式处理这个异常而错失)。

假设：
我们封装一个可以限时中断&捕获任务执行过程中的异常的方法，调用线程通过调用这个方法(传入任务执行的runnable)实现定时中断

1.4.1 思路一 (在外部线程安排中断)

我们可以把这个执行任务的runnable直接在这个方法run()，并且在这个方法中借助ScheduledExecutorService.schedule(Runnable)启动定时中断线程 => 解决了任务执行过程中调用者线程无法捕获未检查异常的问题

出现的问题：

• 如果一，任务执行在取消任务前完成(在时限之前完成)，那么这个定时中断线程必将在这个方法返回调用者线程之后再启动，后果难以预料
  虽然该方法可以返回的ScheduledFuture来取消这个取消任务来避免，但这将给代码带来复杂度
• 如果二：任务执行再取消任务之后完成(超出所设时限)，虽然不会造成难以预料的结果，但是这也我们安排定时任务的前提所违背——超时之后不能及时反馈到调用者线程

1.4.2 思路二 (在外部线程执行任务)

我们可以把任务取消线程、任务执行线程都作为独立的线程在方法中启动 => 保证了超时之后(或者说任务线程不及时响应中断)，及时反馈到调用者线程(中断前执行完成也是一样的，毕竟调用者线程不再受到所执行的任务的影响了)

此时，任务执行都脱离方法(即调用者线程)，未检查异常无法捕获 => 我们可以在任务执行线程中手动捕获，并借助一个volatile类型的throwable,将其保存到该线程，并提供发布throwable的方式

我们的方法中（调用者线程）调用任务执行线程的限时join()，紧接着调用其暴露throwable的方法，取得这个未检查异常 => 解决了未检查异常无法捕获

隐藏的问题：join本身并不会返回一个结果来表明是否成功，这也是Thread API的一个缺陷

1.4.3 思路三 (借组Future类库实现)

伪代码：

	try{
		future.get()
	}catch(TimeoutException){
		//取消任务 => 中断信号及时返回给调用者线程
	}catch(ExecutionException){
		//将这个任务执行过程的异常重新抛出给调用者线程 => 异常直接返回给调用者线程
	}finally{
		//直接取消正在执行的任务线程 => 取消一个不需要返回结果的线程是一个良好的编程习惯(如果不需要返回的结果的时候)
		future.cancel(true)
	}

补充：

• ExecutorService.cancel()直接取消一整个线程池的执行任务
• future.cancel(boolean mayInterruptIfRunning)取消某一个执行任务
  mayInterruptIfRunning
  true:取消正在执行的任务线程
  false:不运行未启动的任务线程
  仅仅表示任务可以接受到中断请求，并不保证任务能够检测并响应这个中断

1.5 处理不可中断的阻塞

在Java库中，许多可阻塞的方法都是通过提前返回或者抛出IE来响应中断请求的，从而使开发人员更容易地构建出能响应取消请求的任务。

并非所有的可阻塞方法或阻塞机制都能响应中断，对于执行不可中断操作而被阻塞的线程，中断请求只能设置线程中断状态，此外却没有任何作用了，只要我们搞清楚线程阻塞的原因，我们一样可以使用类似的中断的手段来停止这些线程。

常见阻塞被不可中断的原因：

• java.io包中的同步SocketIO:
  对套接字进行读取、写入时，read()、write()不会响应中断请求
  可以通过释放套接字，从而使得read()、write()抛出一个SocketException
• java.io包中的同步IO:
  当中断正在InterruptibleChannel上等待的线程时，将抛出ClosedByInterruptException并关闭链路(这将使得链路的所有阻塞的线程抛出CBIE)
  当直接释放整个InterruptibleChannel时，链路上所有阻塞线程都将抛出AsynchronousCloseException,大多数标准的Channel都实现了InterruptibleException
• Selector(java.nio.channels)的异步IO:
  当调用Selector.select()时阻塞了，调用close()、wakeup()方法都将使得线程抛出ClosedSelectorException并提前返回
• 获取某个锁：
  当线程由于等待某个锁而阻塞，那么将无法响应中断，因为线程认为它终将获得这个锁，因此不会理会中断请求
  Lock类的lockInterruptibly()允许等待一个锁的同时仍然能响应中断

1.6 非标准的取消操作

所谓的“非标准的取消操作”，即封装的interrupt()，并实现对不可中断的阻塞的中断支持。
例如：

• 将非标准的取消操作封装在Thread中(继承extends并重写interrupt(),并在重写方法中释放某个Closeable,并在捕获其抛出异常之后，恢复中断)
• 将非标准的取消操作封装在任务中(继承Callable并声明一个返回Future的方法，并在该方法中调用其cancel()，并在获取异常之后调用父类的cancel())
  思路：当一个Callable被提交(submit)至ExecutorService时，将返回一个Future，我们可以声明一个返回Future的工厂方法来参与到其中
  通过任务来操作取消，可以带来更好的灵敏性

2. 停止基于线程的服务

应用程序通常会创建拥有多个线程的服务，例如：线程池，并且这些服务的生命周期通常比创建它们的方法的生命周期更长。

如果应用程序准备退出，那么这些服务所拥有的线程也需要由它们自行退出。

正确的封装原则：除非拥有某个线程，否则不能对该线程进行操控。
线程API中，并没有对线程所有权给出正式的定义：线程由Thread对象表示，并且像其他对象一样可以被自由共享。
然而线程终归有一个相应的所有者，即创建该线程的类。因此线程池是其工作线程的所有者，如果要中断这些线程，应该使用线程池。

与其他封装对象一样，线程的所有权是不能够传递的：服务应该提供给应用程序用于关闭该服务的生命周期方法。
对于持有线程的服务，只要服务的存在时间大于创建线程的方法的存在时间，那么就应该提供生命周期方法。

2.1 关闭 产消模型

通过设置某个“已请求关闭”标志，以避免生产者继续提交，消费者则将队列中的消息悉数消费

如果生产者的提交是通过“先检查后提交”的方式，可能会带有竞态条件，如果队列提交操作已经持锁，那么没有必要再引入一个锁，于是我们可以借助一个递增的计数器并为它加锁。

2.2 关闭ExecutorService

可以通过封装ExecutorService,将所有权链从应用程序扩展到服务以及线程，所有权链上的各个成员都将管理它所拥有的服务或线程的生命周期。

2.3 “毒丸”对象

这是另一种关闭产消模型的方法：
生产者先提交一个“毒丸”对象到队列，并不再提交
当“毒丸”对象被消费者所取出的时候，消费者就停止消费。

该方法可以扩展到多个消费者、生产者。

只有在生产者、消费者的数量都已知的情况下(毕竟触发关闭的“毒丸”对象跟产、消者数量挂钩——生产者需要提交等同于消费者数量的“毒丸”,消费者需要接收到等同于生产者数量的“毒丸”才能关闭服务)，才可以使用“毒丸”对象。
当产、消者数量较大时，这个方法将难以使用。
只有在无界队列中，“毒丸”对象才能可靠的工作。（队列有界可能出现毒丸数量超过其队列长度的情况）

2.4 只执行一次的服务

如果某个方法需要处理一批任务，并且当所有任务都处理完成后才返回，那么可以通过一个私有的Executor来简化服务的生命周期管理。

在这种情况下，invokeAll、invokeAny等方法通常会起到较大的作用。

2.5 shutdownNow的局限性

shutdownNow()返回的Runnable对象可能与提交给ExecutorService的Runnable对象并不相同：它们可能是被封装过的提交任务。

ExecutorService.shutdownNow()将返回尚未开始执行的任务，并不会返回正在执行的任务。
我们可以通过其isShutdown()来找出未开始执行以及正在执行的任务。
但这样做也存在着一个不可避免的竞态条件：
任务在执行最后一条指令以及线程池将任务记录为“结束”的时刻之间，线程池可能被关闭
这可能导致将已取消的任务“误报”为已执行的
如果任务是幂等的，则不需考虑这个风险

2.3 处理非正常的线程终止

导致线程提前死亡的最主要原因是RuntimeException，因为当它们没有被处理或者重新抛出的时候，也将不会在调用栈中逐层传递，而是默认地在控制台输出栈追踪信息，并终止线程。

3.1 未捕获异常的处理

除了主动处理未检查异常，在Thread API中同样提供了UncaughtException,它能够检测出线程由于未捕获的异常而终结的情况。二者结合使用，可以有效地防止线程泄露问题。

当一个线程由于未捕获异常而退出时，JVM会把这个事件报告给应用程序提供的UncaughtExceptionHandler异常处理器，如果没有提供任何的异常处理器，那么默认的行为是将栈追踪信息输出到System.err。

异常处理器除了用来处理未捕获异常，通常还会用于 重启线程、关闭应用程序 或者 修复或诊断等操作。

在运行时间较长的应用程序中，通常会为所有线程的未捕获异常指定同一个异常处理器，并且该处理器至少将异常信息记录到日志中。

要为线程池中的所有线程都设置一个UncaughtExceptionHandler，需要为ThreadPoolExecutor的构造函数提供一个ThreadFactory。

如果希望在任务由于发生异常而失败时获得通知，并且执行一些特定于任务的恢复操作，那么可以将任务封装在能捕获异常的Runnable或Callable中，或者改写ThreadPoolExecutor.afterExecute().。

令人困惑的是，只有通过execute提交的任务，才能将它抛出的异常交给未捕获异常处理器，而通过submit提交的任务，无论是未检查还是已检查的异常都将被认为是返回状态的一部分(Future.get)，并封装到ExecutionException。

4. JVM关闭

JVM既可以正常关闭，也可以强行关闭。

JVM正常关闭：当最后一个“正常(非守护)”线程结束，或调用System.exit()，或通过其他特定平台的方法关闭时(例如发送了SIGNT信号或键入Ctrl-C)。

强行关闭：调用Runtime.halt或者在操作系统中“杀死进程”。

4.1 关闭钩子

在正常关闭中：

• JVM首先将调用所有已注册(Runtime.getRuntime().addShutdownHook())的关闭钩子
  关闭钩子用于清理资源，并且会尽快的退出
  关闭钩子是线程安全的
  守护/非守护线程将于关闭线程并发的执行
  为避免不同服务的关闭操作之间存在竞态条件或死锁等问题，所有服务将使用相同的关闭钩子
• 运行终结器
• JVM停止

4.2 守护线程

线程可分为：普通线程、守护线程(两者的差异仅在于线程推出时的操作)
JVM启动之后，除了主线程之外，其他的线程都是守护线程(GC…)

当JVM停止时，将摈弃守护线程
我们应该尽量少的使用守护线程
守护线程最好用于执行“内部”任务：周期性从内存中移除逾期的数据

守护线程通常不能替代应用程序中各个服务的生命周期

4.3 终结器

当不需要内存资源时，可以通过GC来回收它们，但对于其它一些资源，例如：文件句柄或者套接字句柄，当不需要它们的时候，必须显式地交还给操作系统，为了实现这个功能，GC对哪些定义了finalize()的对象进行了特殊处理：在GC释放它们之后，调用这个方法，从而保证一些持久化的资源被释放。

由于终结器存在许多困难，因此我们应该避免使用终结器。
在大多数情况下，通过finally代码块和close方法能够比使用终结器更好的而资源。
唯有需要管理由本地方法获取的对象的时候，才…