JAVA线程池原理以及几种线程池类型介绍

《JAVA线程池原理以及几种线程池类型介绍》由会员分享，可在线阅读，更多相关《JAVA线程池原理以及几种线程池类型介绍（9页珍藏版）》请在金锄头文库上搜索。

1、在什么情况下使用线程池?1单个任务处理的时间比较短2.将需处理的任务的数量大使用线程池的好处：1减少在创建和销毁线程上所花的时间以及系统资源的开销2如不使用线程池，有可能造成系统创建大量线程而导致消耗完系统内存以及”过度切换”线程池工作原理:为什么要用线程池?诸如Web服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器 应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议(例如HTTP、FTP或POP)、通过JMS队 列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的 情况是：单个任务处理的时间很短而请求的数目却

2、是巨大的。构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创建一 个新线程，然后在新线程中为请求服务。实际上，对于原型开发这种方法工作得 很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程(thread-per-request )方法的不足之一 是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求 的时间和资源更多。除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个JVM里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或

3、“切换过度”。 为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的请 求数目。线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。 这样，就可以 立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程 数目，也就是当请求的数目超过某个阈值时， 就强制其它任何新到的请求一直等 待，直到获得一个线程来处理为止，从而可以防止资源不足。线程池的替代方案线程池远不是服务器应用程序内使用多线程的唯一方法。如同上面所提到的，有时，

4、为每个新任务生成一个新线程是十分明智的。 然而，如果任务创建过于频繁 而任务的平均处理时间过短，那么为每个任务生成一个新线程将会导致性能问 题。另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。AWT和Swing就使用这个模型，在这个模型中有一个GUI事件线程，导致用户界面 发生变化的所有工作都必须在该线程中执行。然而，由于只有一个AWT线程，因此要在AWT线程中执行任务可能要花费相当长时间才能完成， 这是不可取的。 因此,Swing应用程序经常需要额外的工作线程，用于运行时间很长的、同UI有 关的任务。每个任务对应一个线程方法和单个后台线程 (single-backgroun

5、d-thread )方法 在某些情形下都工作得非常理想。每个任务一个线程方法在只有少量运行时间很 长的任务时工作得十分好。而只要调度可预见性不是很重要，则单个后台线程方 法就工作得十分好，如低优先级后台任务就是这种情况。 然而，大多数服务器应 用程序都是面向处理大量的短期任务或子任务，因此往往希望具有一种能够以低 开销有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。线程池提供了这些优点。工作队列就线程池的实际实现方式而言，术语“线程池”有些使人误解，因为线程池“明 显的”实现在大多数情形下并不一定产生我们希望的结果。术语“线程池”先于 Java平台出现，因此它可能是较少面向对象方

6、法的产物。然而，该术语仍继续 广泛应用着。虽然我们可以轻易地实现一个线程池类，其中客户机类等待一个可用线程、将任 务传递给该线程以便执行、然后在任务完成时将线程归还给池，但这种方法却存 在几个潜在的负面影响。例如在池为空时，会发生什么呢？试图向池线程传递任 务的调用者都会发现池为空，在调用者等待一个可用的池线程时，它的线程将阻 塞。我们之所以要使用后台线程的原因之一常常是为了防止正在提交的线程被阻 塞。完全堵住调用者，如在线程池的“明显的”实现的情况，可以杜绝我们试图 解决的问题的发生。我们通常想要的是同一组固定的工作线程相结合的工作队列，它使用wait() 和notify()来通知等待线程新

7、的工作已经到达了。该工作队列通常被实现成具有相关监视器对象的某种链表。清单1显示了简单的合用工作队列的示例。尽管Thread API没有对使用Runnable接口强加特殊要求，但使用 Runnable 对象 队列的这种模式是调度程序和工作队列的公共约定。清单1.具有线程池的工作队列public class WorkQueueprivate final int n Threads;private final PoolWorker threads;private final Lin kedList queue;public WorkQueue(i nt n Threads)this .n Thre

8、ads = n Threads;queue = new Lin kedList();threads = new PoolWorker nThreads;for (int i=0; in Threads; i+) threadsi = new PoolWorker(); threadsi.start();public void execute(R unn able r) synchroni zed(queue) queue.addLast(r);queue .no tify();private class PoolWorker exte nds Thread public void run()

9、Runn able r;while (true) synchroni zed(queue) while (queue.isEmpty() tryqueue.wait();catch (In terruptedExcepti on igno red)r = (Runn able) queue.removeFirst();k/If we dont catch Run timeExcepti on,/ the pool could leak threads try r.run();catch (Run timeExcepti on e) / You might want to log somethi

10、 ng here 您可能已经注意到了清单1中的实现使用的是notify()而不是notifyAII()。大多数专家建议使用n otifyAII()而不是n otify() ，而且理由很充分：使用notify()具有难以捉摸的风险，只有在某些特定条件下使用该方法才是合适的。另一方面，如果使用得当，notify() 具有比notifyAII() 更 可取的性能特征；特别是，n otify()引起的环境切换要少得多，这一点在服务器应用程序中是很重要的。清单1中的示例工作队列满足了安全使用n otify()的需求。因此，请继续，在您的程序中使用它，但在其它情形下使用n otify()时请格外小心。使用

11、线程池的风险虽然线程池是构建多线程应用程序的强大机制，但使用它并不是没有风险的。用 线程池构建的应用程序容易遭受任何其它多线程应用程序容易遭受的所有并发风险，诸如同步错误和死锁，它还容易遭受特定于线程池的少数其它风险，诸如与池有关的死锁、资源不足和线程泄漏。死锁任何多线程应用程序都有死锁风险。当一组进程或线程中的每一个都在等待一个 只有该组中另一个进程才能引起的事件时，我们就说这组进程或线程死锁了。死锁的最简单情形是：线程A持有对象X的独占锁，并且在等待对象丫的锁， 而线程B持有对象丫的独占锁，却在等待对象 X的锁。除非有某种方法来打 破对锁的等待(Java锁定不支持这种方法)，否则死锁的线程

12、将永远等下去。虽然任何多线程程序中都有死锁的风险，但线程池却引入了另一种死锁可能，在那种情况下，所有池线程都在执行已阻塞的等待队列中另一任务的执行结果的任 务，但这一任务却因为没有未被占用的线程而不能运行。当线程池被用来实现涉及许多交互对象的模拟，被模拟的对象可以相互发送查询，这些查询接下来作为 排队的任务执行，查询对象又同步等待着响应时，会发生这种情况。资源不足线程池的一个优点在于：相对于其它替代调度机制(有些我们已经讨论过)而言, 它们通常执行得很好。但只有恰当地调整了线程池大小时才是这样的。线程消耗包括内存和其它系统资源在内的大量资源。除了Thread对象所需的内存之外，每个线程都需要两

13、个可能很大的执行调用堆栈。除此以外，JVM可能会为每个Java线程创建一个本机线程，这些本机线程将消耗额外的系统资源。最后，虽 然线程之间切换的调度开销很小，但如果有很多线程，环境切换也可能严重地影 响程序的性能。如果线程池太大，那么被那些线程消耗的资源可能严重地影响系统性能。在线程 之间进行切换将会浪费时间，而且使用超出比您实际需要的线程可能会引起资源 匮乏问题，因为池线程正在消耗一些资源，而这些资源可能会被其它任务更有效 地利用。除了线程自身所使用的资源以外，服务请求时所做的工作可能需要其它 资源，例如JDBC连接、套接字或文件。这些也都是有限资源，有太多的并发请 求也可能引起失效，例如不

14、能分配 JDBC连接。并发错误线程池和其它排队机制依靠使用 wait() 和notify() 方法，这两个方法都难于 使用。如果编码不正确，那么可能丢失通知，导致线程保持空闲状态，尽管队列 中有工作要处理。使用这些方法时，必须格外小心；即便是专家也可能在它们上 面出错。而最好使用现有的、已经知道能工作的实现，例如在下面的无须编写您自己的池中讨论的util.concurrent包。线程泄漏各种类型的线程池中一个严重的风险是线程泄漏，当从池中除去一个线程以执行一项任务，而在任务完成后该线程却没有返回池时，会发生这种情况。发生线程泄漏的一种情形出现在任务抛出一个 Run timeException

15、或一个Error 时。如 果池类没有捕捉到它们，那么线程只会退出而线程池的大小将会永久减少一个。 当这种情况发生的次数足够多时， 线程池最终就为空，而且系统将停止，因为没 有可用的线程来处理任务。有些任务可能会永远等待某些资源或来自用户的输入，而这些资源又不能保证变得可用，用户可能也已经回家了，诸如此类的任务会永久停止，而这些停止的任 务也会引起和线程泄漏同样的问题。如果某个线程被这样一个任务永久地消耗 着，那么它实际上就被从池除去了。 对于这样的任务，应该要么只给予它们自己 的线程，要么只让它们等待有限的时间。请求过载仅仅是请求就压垮了服务器，这种情况是可能的。在这种情形下，我们可能不想 将每个到来的请求都排队到我们的工作队列，因为排在队列中等待执行的任务可能会消耗太多的系统资源并引起资源缺乏。 在这种情形下决定如何做取决于您自己；在某些情况下，您可以简单地抛弃请求，依靠更高级别的协议稍后重试请求， 您也可以用一个指出服务器暂时很忙的响应来拒绝请求。有效使用线程池的准则只要您遵循几条简单的准则，线程池可以成为构建服务器应用程序的极其有效的 方法：不