Java理论与实践: 线程池与工作行列[Java编程]

为什么要用线程池?

诸如 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 对 象行列的这种情势是调度程序和工作行列的大众约定.

　　以上是“Java理论与实践: 线程池与工作行列[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：