【概述】
与数据库连接管理类似，线程的创建和销毁会耗费较大的开销，使用 “池化技术” 来更好地利用当前线程资源，减少因线程创建和销毁带来的开销，这就是线程池产生的原因。
【无限创建线程的不足】
在生产环境中，若没有线程池，则需要采用的是 “为每个任务创建一个线程” 的方法，当出现大量的请求时需要创建大量的线程：
- 线程生命周期的开销非常高：线程的创建和销毁并不是没有代价的。根据平台的不同，实际的开销也有所不同，但线程的创建过程都需要时间，延迟处理的请求，并且需要 JVM 和操作系统提供一些辅助操作。如果请求的到达率非常高且请求的处理过程是轻量级的，例如大多数服务器应用程序就是这种情况，那么为每个请求创建一个新线程将消耗大量的计算资源。
- 资源消耗：活跃的线程会消耗系统资源，尤其是内存。如果可运行的线程数量多于可用处理器的数量，那么有些线程将闲置。大量空闲的线程会占用许多内存，给垃圾回收器带来压力，而且大量线程在竞争 CPU 资源时还将产生其他的性能开销。如果你已经拥有足够多的线程使 CPU 保持忙碌状态，那么再创建更多的线程反而会降低性能。
- 稳定性：在可创建线程的数量上存在一个限制。这个限制值将随着平台的不同而不同，并且受多个因素制约，包括 JVM 的启动参数、Thread 构造函数中请求的栈大小，以及底层操作系统对线程的限制等。如果破坏了这些限制，那么很可能会抛出 OOM 异常，要想从这种错误中恢复过来是非常危险的，更简单的方法是通过构造程序来避免超出这些限制。
在一定的范围内，增加线程可以提供系统的吞吐率，但如果超出了这个范围，再创建再多的线程只会降低程序的执行速度，并且如果过多地创建一个线程，那么整个应用程序将会崩溃。要想避免这种危险，就应该对应用程序可以创建的线程数量进行限制，并且全面地测试应用程序，从而确保在线程数量达到限制时，程序也也不会耗尽资源。
“为每个任务分配一个线程” 这种方法的问题在于，它没有限制可创建线程的数量，只限制了远程用户提交 HTTP 请求的速率。与其他的并发危险一样，在原型设计和开发阶段，无限制地创建线程或许还能较好地运行，但在应用程序部署后并处于高负载下运行时，才会有问题不断地暴露出来。因此，某个恶意的用户或者过多的用户，都会使 Web 服务器的负载达到某个阈值，从而使服务器崩溃。如果服务器需要提供高可用性，并且在高负载情况下能平缓地降低性能，那么这将是一个严重的故障。