Java 理论与实践:线程池与工作队列
几乎在每个服务器应用程序中都会出现线程池和工作队列问题。本文中, Brian Goetz 探讨了线程池的动
机、一些基本实现和调优技术以及一些要避免的常见危险。 为什么要用线程池? 诸如 Web 服务器、数
据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短
小的任务。请求以某种方式到达服务器,这种方式可能是通过网络协议(例如 HTTP、FTP 或 POP)、
通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达,服务器应用程序中经常出现的情况是:单
个任务处理的时间很短而请求的数目却是巨大的。
为什么要用线程池?
诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序
都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器,这种方式
可能是通过网络协议(例如 HTTP、FTP 或 POP)、通过 JMS 队列或者可能通过轮询数
据库。不管请求如何到达,服务器应用程序中经常出现的情况是:单个任务处理的时间很
短而请求的数目却是巨大的。
构建服务器应用程序的一个过于简单的模型应该是:每当一个请求到达就创建一个新线程,
然后在新线程中为请求服务。实际上,对于原型开发这种方法工作得很好,但如果试图部
署以这种方式运行的服务器应用程序,那么这种方法的严重不足就很明显。每个请求对应
一个线程(thread-per-request)方法的不足之一是:为每个请求创建一个新线程的开销很
大;为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要
比花在处理实际的用户请求的时间和资源更多。
除了创建和销毁线程的开销之外,活动的线程也消耗系统资源。在一个 JVM 里创建太多的
线程可能会导致系统由于过度消耗内存而用完内存或“切换过度”。为了防止资源不足,服
务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。
线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线
程,线程创建的开销被分摊到了多个任务上。其好处是,因为在请求到达时线程已经存在,
所以无意中也消除了线程创建所带来的延迟。这样,就可以立即为请求服务,使应用程序
响应更快。而且,通过适当地调整线程池中的线程数目,也就是当请求的数目超过某个阈
值时,就强制其它任何新到的请求一直等待,直到获得一个线程来处理为止,从而可以防
止资源不足。
线程池的替代方案
线程池远不是服务器应用程序内使用多线程的唯一方法。如同上面所提到的,有时,为每个新任务生成一个新线程是十分明智的。然而,
如果任务创建过于频繁而任务的平均处理时间过短,那么为每个任务生成一个新线程将会导致性能问题。
另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。AWT 和 Swing 就使用这个模型,在这个模型中有一个 GUI
事件线程,导致用户界面发生变化的所有工作都必须在该线程中执行。然而,由于只有一个 AWT 线程,因此要在 AWT 线程中执行任
务可能要花费相当长时间才能完成,这是不可取的。因此,Swing 应用程序经常需要额外的工作线程,用于运行时间很长的、同 UI 有
关的任务。
每个任务对应一个线程方法和单个后台线程(single-background-thread)方法在某些情形下都工作得非常理想。每个任务一个线程方
法在只有少量运行时间很长的任务时工作得十分好。而只要调度可预见性不是很重要,则单个后台线程方法就工作得十分好,如低优先
级后台任务就是这种情况。然而,大多数服务器应用程序都是面向处理大量的短期任务或子任务,因此往往希望具有一种能够以低开销
有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。线程池提供了这些优点。
工作队列