为什么要用线程池？
诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务 器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到 达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP 或 POP）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常 出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。
构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创 建一个新线程，然后在新线程中为请求服务。实际上，对于原型开发这种方法工 作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的 严重不足就很明显。每个请求对应一个线程（thread-per-request）方法的不足 之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务 器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请 求的时间和资源更多。
除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或“切换过度” 。为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的 请求数目。
线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多 个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请 求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就 可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的 线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一 直等待，直到获得一个线程来处理为止，从而可以防止资源不足。
线程池的替代方案
线程池远不是服务器应用程序内使用多线程的唯一方法。如同上面所提到的 ，有时，为每个新任务生成一个新线程是十分明智的。然而，如果任务创建过于 频繁而任务的平均处理时间过短，那么为每个任务生成一个新线程将会导致性能 问题。
另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。 AWT 和 Swing 就使用这个模型，在这个模型中有一个 GUI 事件线程，导致用户 界面发生变化的所有工作都必须在该线程中执行。然而，由于只有一个 AWT 线 程，因此要在 AWT 线程中执行任务可能要花费相当长时间才能完成，这是不可 取的。因此，Swing 应用程序经常需要额外的工作线程，用于运行时间很长的、 同 UI 有关的任务。
每个任务对应一个线程方法和单个后台线程（single-background-thread） 方法在某些情形下都工作得非常理想。每个任务一个线程方法在只有少量运行时 间很长的任务时工作得十分好。而只要调度可预见性不是很重要，则单个后台线 程方法就工作得十分好，如低优先级后台任务就是这种情况。然而，大多数服务 器应用程序都是面向处理大量的短期任务或子任务，因此往往希望具有一种能够 以低开销有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。 线程池提供了这些优点。
工作队列
就线程池的实际实现方式而言，术语“线程池”有些使人误解，因为线程池 “明显的”实现在大多数情形下并不一定产生我们希望的结果。术语“线程池” 先于 Java 平台出现，因此它可能是较少面向对象方法的产物。然而，该术语仍 继续广泛应用着。
虽然我们可以轻易地实现一个线程池类，其中客户机类等待一个可用线程、 将任务传递给该线程以便执行、然后在任务完成时将线程归还给池，但这种方法 却存在几个潜在的负面影响。例如在池为空时，会发生什么呢？试图向池线程传 递任务的调用者都会发现池为空，在调用者等待一个可用的池线程时，它的线程 将阻塞。我们之所以要使用后台线程的原因之一常常是为了防止正在提交的线程 被阻塞。完全堵住调用者，如在线程池的“明显的”实现的情况，可以杜绝我们 试图解决的问题的发生。
我们通常想要的是同一组固定的工作线程相结合的工作队列，它使用 wait() 和 notify() 来通知等待线程新的工作已经到达了。该工作队列通常被实现成具 有相关监视器对象的某种链表。清单 1 显示了简单的合用工作队列的示例。尽 管 Thread API 没有对使用 Runnable 接口强加特殊要求，但使用 Runnable 对 象队列的这种模式是调度程序和工作队列的公共约定。