大多数并发应用程序都是围绕 “任务执行 (Task Execution)" 来构造的：任务通常是一些抽象的且离散的工作单元。 通过把应用程序的工作分解到多个任务中， 可以简化程序的组织结构， 提供一种自然的事务边界来优化错误恢复过程， 以及提供一种自然的并行工作结构来提升并发性。
在线程中执行任务
当围绕 “任务执行” 来设计应用程序结构时，第一步就是要找出清晰的任务边界。 在理想情况下， 各个任务之间是相互独立的：任务并不依赖于其他任务的状态、结果或边界效应。 独立性有助于实现并发， 因为如果存在足够多的处理资源，那么这些独立的任务都可以并行执行。 为了在调度与负载均衡等过程中实现更高的灵活性， 每项任务还应该表示应用程序的一小部分处理能力。
在正常的负载下，服务器应用程序应该同时表现出良好的吞吐量和快速的响应性。应用程序提供商希望程序支持尽可能多的用户， 从而降低每个用户的服务成本， 而用户则希望获得尽快的响应。 而且， 当负荷过载时， 应用程序的性能应该是逐渐降低， 而不是直接失败。 要实现上述目标， 应该选择清晰的任务边界以及明确的任务执行策略。
大多数服务器应用程序都提供了一种自然的任务边界选择方式：以独立的客户请求为边界。 Web服务器、 邮件服务器、 文件服务器、EJB容器以及数据库服务器等， 这些服务器都能通过网络接受远程客户的连接请求。将独立的请求作为任务边界，既可以实现任务的独立性，又可以实现合理的任务规模。例如，在向邮件服务器提交一个消息后得到的结果，井不会受其他正在处理的消息影响，而且在处理单个消息时通常只需要服务器总处理能力的很小一部分。
串行地执行任务
在应用程序中可以通过多种策略来调度任务，而其中一些策略能够更好地利用潜在的并发性。最简单的策略就是在单个线程中串行地执行各项任务。程序清单6-1中的SingleThreadWebServer将串行地处理它的任务（即通过80端口接收到的HTTP请求）。至于如何处理请求的细节问题， 在这里并不重要， 我们感兴趣的是如何表征不同调度策略的同步特性。
SingleThreadWebServer 很简单， 且在理论上是正确的， 但在实际生产环境中的执行性能却很糟糕， 因为它每次只能处理一个请求。主线程在接受连接与处理相关请求等操作之间不断地交替运行。当服务器正在处理请求时， 新到来的连接必须等待直到请求处理完成， 然后服务器将再次调用accept。如果处理请求的速度很快并且handleRequest 可以立即返回， 那么这种方法是可行的， 但现实世界中的Web服务器的情况却并非如此。
在Web请求的处理中包含了一组不同的运算与I/0操作。服务器必须处理套接字I/O以读取请求和写回响应，这些操作通常会由于网络拥塞或连通性问题而被阻塞。此外， 服务器还可能处理文件I/O或者数据库请求， 这些操作同样会阻塞。在单线程的服务器中， 阻塞不仅会推迟当前请求的完成时间， 而且还将彻底阻止等待中的请求被处理。如果请求阻塞的时间过长，用户将认为服务器是不可用的， 因为服务器看似失去了响应。同时， 服务器的资源利用率非常低， 因为当单线程在等待1/0操作完成时，CPU将处于空闲状态。
在服务器应用程序中， 串行处理机制通常都无法提供高吞吐率或快速响应性。也有一些例外， 例如， 当任务数量很少且执行时间很长时， 或者当服务器只为单个用户提供服务， 并且该客户每次只发出一个请求时——但大多数服务器应用程序并不是按照这种方式来工作的.
显式地为任务创建线程
通过为每个请求创建一个新的线程来提供服务，从而实现更高的响应性，如程序清单6-2中的ThreadPerTaskWebServer所示。
ThreadPerTaskWebServer在结构上类似于前面的单线程版本——主线程仍然不断地交替执行“接受外部连接” 与“分发请求” 等操作。区别在于，对于每个连接，主循环都将创建一个新线程来处理请求，而不是在主循环中进行处理。由此可得出3个主要结论：
a.任务处理过程从主线程中分离出来， 使得主循环能够更快地重新等待下一个到来的连接。这使得程序在完成前面的请求之前可以接受新的请求， 从而提高响应性。
b.任务可以并行处理， 从而能同时服务多个请求。如果有多个处理器， 或者任务由于某种原因被阻塞， 例如等待I/O完成、获取锁或者资源可用性等， 程序的吞吐量将得到提高。
c.任务处理代码必须是线程安全的， 因为当有多个任务时会并发地调用这段代码。
在正常负载情况下， “为每个任务分配一个线程” 的方法能提升串行执行的性能。只要请求的到达速率不超出服务器的请求处理能力， 那么这种方法可以同时带来更快的响应性和更高的吞吐率。
无限制创建线程的不足
在生产环境中，“为每个任务分配一个线程” 这种方法存在一些缺陷， 尤其是当需要创大量的线程时：
a.线程生命周期的开销非常高。线程的创建与销毁并不是没有代价的。根据平台的不同， 实际的开销也有所不同， 但线程的创建过程都会需要时间， 延迟处理的请求， 并且需要JVM和操作系统提供一些辅助操作。如果请求的到达率非常高且请求的处理过程是轻最级的， 例如大多数服务器应用程序就是这种情况， 那么为每个请求创建一个新线程将消耗大量的计算资源。
b.资源消耗。活跃的线程会消耗系统资源， 尤其是内存。如果可运行的线程数量多于可用处理器的数量，那么有些线程将闲置。大量空闲的线程会占用许多内存，给垃圾回收器带来压力，而且大量线程在竞争CPU资源时还将产生其他的性能开销。如果你已经拥有足够多的线程使所有CPU保持忙碌状态，那么再创建更多的线程反而会降低性能。
c.稳定性。在可创建线程的数量上存在一个限制。这个限制值将随着平台的不同而不同， 并且受多个因素制约， 包括JVM的启动参数、Thread构造函数中请求的栈大小， 以及底层操作系统对线程的限制等。如果破坏了这些限制， 那么很可能抛出OutOfMemoryError 异常，想从这种错误中恢复过来是非常危险的， 更简单的办法是通过构造程序来避免超出这些限制。
在一定的范围内， 增加线程可以提高系统的吞吐率， 但如果超出了这个范围， 再创建更多的线程只会降低程序的执行速度， 并且如果过多地创建一个线程， 那么整个应用程序将崩溃。要想避免这种危险， 就应该对应用程序可以创建的线程数最进行限制， 并且全面地测试应用程序， 从而确保在线程数量达到限制时， 程序也不会耗尽资源。
“为每个任务分配一个线程” 这种方法的问题在于， 它没有限制可创建线程的数量， 只限制了远程用户提交HTTP 请求的速率。与其他的并发危险一样， 在原型设计和开发阶段， 无限制地创建线程或许还能较好地运行， 但在应用程序部署后井处于高负载下运行时， 才会有问题不断地暴露出来。因此， 某个恶意的用户或者过多的用户， 都会使Web 服务器的负载达到某个阅值， 从而使服务器崩溃。如果服务器需要提供高可用性， 并且在高负载情况下能平缓地降低性能， 那么这将是一个严重的故障。
Executor框架
任务是一组逻辑工作单元， 而线程则是使任务异步执行的机制。我们已经分析了两种通过线程来执行任务的策略， 即把所有任务放在单个线程中串行执行， 以及将每个任务放在各自的线程中执行。这两种方式都存在一些严格的限制：串行执行的问题在于其糟糕的响应性和吞吐量， 而“为每个任务分配一个线程” 的问题在于资源管理的复杂性。
在第5章中， 我们介绍了如何通过有界队列来防止高负荷的应用程序耗尽内存。线程池简化了线程的管理工作， 并且java.util.concurrent 提供了一种灵活的线程池实现作为Executor 框架的一部分。在Java 类库中， 任务执行的主要抽象不是Thread, 而是Executor, 如程序清单6-3 所示。
虽然Executor 是个简单的接口， 但它却为灵活且强大的异步任务执行框架提供了基础，该框架能支持多种不同类型的任务执行策略。它提供了一种标准的方法将任务的提交过程与执行过程解耦开来， 并用Runnable 来表示任务。Executor 的实现还提供了对生命周期的支持， 以及统计信息收集、应用程序管理机制和性能监视等机制。
Executor 基于生产者－ 消费者模式，提交任务的操作相当于生产者（生成待完成的工作单元），执行任务的线程则相当于消费者（执行完这些工作单元）。如果要在程序中实现一个生产者－ 消费者的设计，那么最简单的方式通常就是使用Executor 。
示例：基于Executor的Web服务器
基于Executor来构建Web服务器是非常容易的。在程序清单6-4中用Executor 代替了硬编码的线程创建过程。在这种情况下使用了一种标准的Executor实现， 即一个固定长度的线程池， 可以容纳100个线程。
在TaskExecutionWebServer中， 通过使用Executor, 将请求处理任务的提交与任务的实际执行解耦开来， 井且只需采用另一种不同的Executor实现， 就可以改变服务器的行为。改变Executor实现或配置所带来的影响要远远小千改变任务提交方式带来的影响。通常，Executor的配置是一次性的， 因此在部署阶段可以完成， 而提交任务的代码却会不断地扩散到整个程序中， 增加了修改的难度。
我们可以很容易地将TaskExecutionWebServer修改为类似ThreadPerTaskWebServer的行为， 只需使用一个为每个请求都创建新线程的Executor。编写这样的Executor很简单， 如程序清单6-5中的ThreadPerTaskExecutor所示。
同样， 还可以编写一个Executor使TaskExecutionWebServer的行为类似于单线程的行为，即以同步的方式执行每个任务， 然后再返回， 如程序清单6-6中的Withi nThreadExecutor所示。
执行策略
通过将任务的提交与执行解耦开来， 从而无须太大的困难就可以为某种类型的任务指定和修改执行策略。在执行策略中定义了任务执行的"What 、Where 、When、How" 等方面， 包括：
a.在什么(What) 线程中执行任务？
b.任务安照什么(What) 顺序执行(FIFO、LIFO 、优先级）？
c.有多少个(How Many) 任务能并发执行？
d.在队列中有多少个(How Many) 任务在等待执行？
e.如果系统由于过载而需要拒绝一个任务， 那么应该选择哪一个(Which) 任务？另外，如何(How) 通知应用程序有任务被拒绝？
f.在执行一个任务之前或之后，应该进行哪些(What) 动作？
各种执行策略都是一种资源管理工具， 最佳策略取决于可用的计算资源以及对服务质益的需求。通过限制并发任务的数量， 可以确保应用程序不会由于资源耗尽而失败， 或者由于在稀缺资源上发生竞争而严重影响性能。通过将任务的提交与任务的执行策略分离开来， 有助于在部署阶段选择与可用硬件资源最匹配的执行策略。
每当看到下面这种形式的代码时：
new Thread(runnable).start（）
并且你希望获得一种更灵活的执行策略时， 请考虑使用Executor 来代替Thread。
线程池
线程池，从字面含义来看，是指管理一组同构工作线程的资源池。线程池是与工作队列(Work Queue) 密切相关的，其中在工作队列中保存了所有等待执行的任务。工作者线程(Worker Thread) 的任务很简单：从工作队列中获取一个任务，执行任务，然后返回线程池并等待下一个任务。
“在线程池中执行任务” 比“为每个任务分配一个线程” 优势更多。通过重用现有的线程而不是创建新线程，可以在处理多个请求时分摊在线程创建和销毁过程中产生的巨大开销。另一个额外的好处是，当请求到达时，工作线程通常已经存在，因此不会由于等待创建线程而延迟任务的执行， 从而提高了响应性。通过适当调整线程池的大小， 可以创建足够多的线程以便使处理器保持忙碌状态， 同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或失败。
类库提供了一个灵活的线程池以及一些有用的默认配置。可以通过调用Executors中的静态工厂方法之一来创建一个线程池：
a.newFixedThreadPool。newFixedThreadPool将创建一个固定长度的线程池， 每当提交一个任务时就创建一个线程， 直到达到线程池的最大数量， 这时线程池的规模将不再变化（如果某个线程由于发生了未预期的Exception而结束， 那么线程池会补充一个新的线程）。
b.newCachedThreadPool。newCachedThreadPool将创建一个可缓存的线程池，如果线程池的当前规模超过了处理需求时，那么将回收空闲的线程，而当需求增加时，则可以添加新的线程，线程池的规模不存在任何限制。
c.newSingleThreadExecutor。newSingleThreadExecutor是一个单线程的Executor, 它创建单个工作者线程来执行任务， 如果这个线程异常结束， 会创建另一个线程来替代。newSingleThreadExecutor能确保依照任务在队列中的顺序来串行执行（例如FIFO、LIFO、优先级）。
d.newScheduledThreadPool. newSched uledThreadPool创建了一个固定长度的线程池， 而
且以延迟或定时的方式来执行任务， 类似千Timer (参见6.2.5节）。
e.newFixedThreadPool和newCachedThreadPool这两个工厂方法返回通用的ThreadPoolExecutor实例， 这些实例可以直接用来构造专门用途的executor。我们将在第8章中深入讨论线程池的各个配置选项。
f.TaskExecutionWebServer中的Web服务器使用了一个带有有界线程池的Executor。 通过execute方法将任务提交到工作队列中，工作线程反复地从工作队列中取出任务并执行它们。
从“ 为每任务分配一个线程” 策略变成基于线程池的策略， 将对应用程序的稳定性产生重大的影响： Web服务器不会再在高负载情况下失败。由于服务器不会创建数千个线程来争夺有限的CPU和内存资源， 因此服务器的性能将平缓地降低。通过使用Executor, 可以实现各种调优、管理、监视、记录日志、错误报告和其他功能，如果不使用任务执行框架，那么要增加这些功能是非常困难的。
Executor的生命周期
我们已经知道如何创建一个Executor, 但并没有讨论如何关闭它。Executor的实现通常会创建线程来执行任务。但JVM只有在所有（非守护）线程全部终止后才会退出。因此，如果无法正确地关闭Executor, 那么JVM将无法结束。
由于Executor以异步方式来执行任务，因此在任何时刻，之前提交任务的状态不是立即可见的。有些任务可能已经完成，有些可能正在运行，而其他的任务可能在队列中等待执行。当关闭应用程序时，可能采用最平缓的关闭形式（完成所有已经启动的任务， 并且不再接受任何新的任务），也可能采用最粗暴的关闭形式（直接关掉机房的电源）， 以及其他各种可能的形式。既然Executor 是为应用程序提供服务的， 因而它们也是可关闭的（无论采用平缓的方式还是粗暴的方式），并将在关闭操作中受影响的任务的状态反馈给应用程序。
为了解决执行服务的生命周期问题， Executor 扩展了ExecutorService 接口， 添加了一些用于生命周期管理的方法（同时还有一些用于任务提交的便利方法）。在程序清单6-7 中给出ExecutorService 中的生命周期管理方法。
ExecutorService 的生命周期有3 种状态：运行、关闭和巳终止。ExecutorService 在初始创建时处于运行状态。shutdown 方法将执行平缓的关闭过程：不再接受新的任务，同时等待已经提交的任务执行完成一包括那些还未开始执行的任务。shutdownNow 方法将执行粗暴的关闭过程： 它将尝试取消所有运行中的任务， 并且不再启动队列中尚未开始执行的任务。
在ExecutorService 关闭后提交的任务将由“ 拒绝执行处理器(Rejected Execution Handler)"来处理， 它会抛弃任务，或者使得execute 方法抛出一个未检查的RejectedExecutionException。等所有任务都完成后， ExecutorService 将转入终止状态。可以调用awaitTermination 来等待ExecurService 到达终止状态， 或者通过调用isTerminated 来轮询ExecutorService 是否已经终止。通常在调用awaitTermination 之后会立即调用shutdown, 从而产生同步地关闭ExecutorService 的效果。
程序清单6-8 的LifecycleWebServer 通过增加生命周期支持来扩展Web 服务器的功能。可以通过两种方法来关闭Web 服务器： 在程序中调用stop, 或者以客户端请求形式向Web 服务器发送一个特定格式的HTTP 请求。
Timer 类负责管理延迟任务("在100ms 后执行该任务")以及周期任务("每10s 执行一次该任务")。然而， Timer 存在一些缺陷， 因此应该考虑使用ScheduledThreadPoolExecutor 来代替它。可以通过ScheduledThreadPoolExecutor 的构造函数或newScheduledThreadPool工厂方法来创建该类的对象。
Timer 在执行所有定时任务时只会创建一个线程。如果某个任务的执行时间过长， 那么将破坏其他TimerTask 的定时精确性。例如某个周期TimerTask 需要每10ms 执行一次， 而另一个TimerTask 需要执行40ms, 那么这个周期任务或者在40ms 任务执行完成后快速连续地调用4次， 或者彻底“ 丢失”4 次调用（取决于它是基于固定速率来调度还是基于固定延时来调度）。线程池能弥补这个缺陷， 它可以提供多个线程来执行延时任务和周期任务。
Timer 的另一个问题是 如果TimerTask 抛出了一个未检查的异常，那么Timer 将表现出糟糕的行为。Timer 线程并不捕获异常， 因此当TimerTask 抛出未检查的异常时将终止定时线程。这种情况下， Timer也不会恢复线程的执行， 而是会错误地认为整个Timer 都被取消。因此， 已经被调度但尚未执行的TimerTask 将不会再执行，新的任务也不能被调度。（这个问题称之为“线程泄涌[Thread Leakage] "。）
在程序清单6-9 的OutOfTime 中给出了Timer 中为什么会出现这种问题， 以及如何使得试图提交TimerTask 的调用者也出现问题。你可能认为程序会运行6 秒后退出， 但实际情况是运行1秒就结束了，并抛出了一个异常消息"Timeralready cancelled"。 ScheduledThreadPoolExecutor能正确处理这些表现出错误行为的任务。在Java5.0或更高的JDK中，将很少使用Timer。
如果要构建自己的调度服务，那么可以使用DelayQueue,它实现了BlockingQueue,并 为ScheduledThreadPoolExecutor提供调度功能。DelayQueue管理着组Delayed对象。每一 个Delayed对象都有一个相应的延迟时间：在DelayQueue中，只有某个元素逾期后，才能从 DelayQueue中执行take操作。从DelayQueue中返回的对象将根据它们的延迟时间进行排序。
找出可利用的并行性
Executor 框架帮助指定执行策略， 但如果要使用Executor, 必须将任务表述为一个Runnable。在大多数服务器应用程序中都存在一个明显的任务边界：单个客户请求。但有时候，任务边界并非是显而易见的， 例如在很多桌面应用程序中。即使是服务器应用程序， 在单个客户请求中仍可能存在可发掘的并行性， 例如数据库服务器。（请参见[CPJ 4.4.1.1]了解在选择任务边界时的各种权衡因素及相关讨论。）
携带结果的任务Callable与Future
Executor框架使用Runnable作为其基本的任务表示形式。Runnable是一种有很大局限的抽象， 虽然run能写入到日志文件或者将结果放入某个共享的数据结构， 但它不能返回一个值或抛出一个受检查的异常。
许多任务实际上都是存在延迟的计算——执行数据库查询， 从网络上获取资源， 或者计算某个复杂的功能。对于这些任务，Callable是一种更好的抽象： 它认为主入口点（即call)将返回一个值， 井可能抛出一个异常。在Executor中包含了一些辅助方法能将其他类型的任务封装为一个Callable, 例如Runnable和java.security.PrivilegedAction。
Runnable和Callable描述的都是抽象的计算任务。这些任务通常是有范围的， 即都有一个明确的起始点， 并且最终会结束。Executor 执行的任务有4个生命周期阶段： 创建、提交、开始和完成。由于有些任务可能要执行很长的时间， 因此通常希望能够取消这些任务。在Executor框架中， 已提交但尚未开始的任务可以取消， 但对于那些已经开始执行的任务， 只有当它们能响应中断时， 才能取消。取消一个已经完成的任务不会有任何影响。
Future 表示一个任务的生命周期， 井提供了相应的方法来判断是否已经完成或取消， 以及获取任务的结果和取消任务等。在程序清单6-11中给出了Callable和Future。在Future规范中包含的隐含意义是， 任务的生命周期只能前进， 不能后退， 就像ExecutorService 的生命周期一样。当某个任务完成后， 它就永远停留在“完成” 状态上。
get 方法的行为取决于任务的状态（尚未开始、正在运行、已完成）。如果任务已经完成，那么 get 会立即返回或者抛出一个 Exception, 如果任务没有完成， 那么 get将阻塞并直到任务 完成。 如果任务抛出了异常， 那么 get 将该异常封装为 ExecutionException 并重新抛出。 如果 任务被取消，那么 get 将抛出CancellationException。如果 get 抛出了ExecutionException, 那么可以通过 getCause 来获得被封装的初始异常。
可以通过许多种方法创建一个Future 来描述任务。ExecutorService 中的所有submit 方法都将返回一个Future, 从而将一个Runnable 或Callable 提交给Executor, 并得到一个Future 用来获得任务的执行结果或者取消任务。还可以显式地为某个指定的Runnable 或Callable 实例化一个FutureTask。（由于FutureTask 实现了Runnable, 因此可以将它提交给Executor 来执行，或者直接调用它的run 方法。）
从Java6 开始， ExecutorService 实现可以改写AbstractExecutorService 中的newTaskFor方法， 从而根据已提交的Runnable 或Callable 来控制Future 的实例化过程。在默认实现中仅创建了一个新的FutureTask, 如程序清单6-12 所示。
在将Runnable 或Callable 提交到Executor 的过程中， 包含了一个安全发布过程，即将Runnable或Callable 从提交线程发布到最终执行任务的线程。类似地， 在设置Future 结果的过程中也包含了一个安全发布， 即将这个结果从计算它的线程发布到任何通过get获得它的线程。
CompletionService:Executor与BlockingQueue
如果向Executor提交了一组计算任务， 并且希望在计算完成后获得结果， 那么可以保留与 每个任务关联的Future, 然后反复使用get方法，同时将参数 timeout指定为 o, 从而通过轮询来判断任务是否完成。 这种方法虽然可行， 但却有些繁琐。 幸运的是， 还有一种更好的方法： 完成服务(CompletionService)。
CompletionService将Executor和BlockingQueue的功能融合在一起。你可以将 Callable任 务提交给它来执行， 然后使用类似千队列操作的 take和poll等方法来获得已完成的结果， 而这 些结果会在完成时将被封装为Future。ExecutorCompletionService实现了 CompletionService, 并将计算部分委托给一个Executor。
ExecutorCompletionService的实现非常简单。 在构造函数中创建一个BlockingQueue来保 存计算完成的结果 。当计算完成时， 调用Future-Task中的don e方法。当提交某个任务时， 该 任务将首先包装为一个QueueingFuture, 这是FutureTask的一个子类， 然后再改写子类的don e 方法， 并将结果放入BlockingQueue中，如程序 清单 6-14 所示。take和poll方法委托给了BlockingQueue, 这些方法会在得出结果之前阻塞。
为任务设置时限
有时候， 如果某个任务无法在指定时间内完成，那么将不再需要它的结果，此时可以放弃这个任务。 例如，某个Web应用程序从外部的广告服务器上获取广告信息，但如果该应用程序 在两秒钟内得不到响应，那么将显示一个默认的广告，这样即使不能获得广告信息，也不会降低站点的响应性能。类似地，一个门户网站可以从多个数据源并行地获取数据，但可能只会在 指定的时间内等待数据， 如果超出了等待时间，那么只显示已经获得的数据。
在有限时间内执行任务的主要困难在于，要确保得到答案的时间不会超过限定的时间， 或者在限定的时间内无法获得答案。在支持时间限制的Future.get中支持这种需求： 当结果可用 时， 它将立即返回， 如果在指定时限内没有计算出结果，那么将抛出TimeoutException。
在使用限时任务时需要注意，当这些任务超时后应该立即停止，从而避免为继续计算一 个不再使用的结果而浪费计算资源。要实现这个功能， 可以由任务本身来管理它的限定时间， 并且在超时后中止执行或取消任务。此时可再次使用Future, 如果一个限时的get方法抛出了 TimeoutException, 那么可以通过Future来取消任务。如果编写的任务是可取消的（参见第7 章），那么可以提前中止它，以免消耗过多的资源。在程序清单6-13和6-16的代码中使用了这 项技术。
程序清单6-16给出了限时Future.get的一种典型应用。在它生成的页面中包括响应用户请求的内容以及从广告服务器上获得的广告。它将获取广告的任务提交给一个Executor, 然后计算剩余的文本页面 内容， 最后 等待广告信息，直到超出指定的时间。如果get 超时， 那么将取消广告获取任务， 并转而使用默认的广告信息。
网友评论