线程池的原理及实现及问题

来源:互联网 发布:快速排序算法c语言实现 编辑:程序博客网 时间:2024/06/06 07:05

线程池的原理及实现



、线程池简介


    多线程技术主要解决处理器单元内多个线程执行的问题,它可以显著减少处理器单元的闲置时间,增加处理器单元的吞吐能力。

    假设一个服务器完成一项任务所需时间为:T1 创建线程时间,T2 在线程中执行任务的时间,T3 销毁线程时间。

    如果:T1 + T3 远大于 T2,则可以采用线程池,以提高服务器性能。

一个线程池包括以下四个基本组成部分:

1、线程池管理器(ThreadPool):用于创建并管理线程池,包括 创建线程池,销毁线程池,添加新任务;

2、工作线程(PoolWorker):线程池中线程,在没有任务时处于等待状态,可以循环的执行任务;

3、任务接口(Task):每个任务必须实现的接口,以供工作线程调度任务的执行,它主要规定了任务的入口,任务执行完后的收尾工作,任务的执行状态等;

4、任务队列(taskQueue):用于存放没有处理的任务。提供一种缓冲机制。


    线程池技术正是关注如何缩短或调整T1,T3时间的技术,从而提高服务器程序性能的。它把T1,T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段,这样在服务器程序处理客户请求时,不会有T1,T3的开销了。

    线程池不仅调整T1,T3产生的时间段,而且它还显著减少了创建线程的数目,看一个例子:

    假设一个服务器一天要处理50000个请求,并且每个请求需要一个单独的线程完成。在线程池中,线程数一般是固定的,所以产生线程总数不会超过线程池中线程的数目,而如果服务器不利用线程池来处理这些请求则线程总数为50000。一般线程池大小是远小于50000。所以利用线程池的服务器程序不会为了创建50000而在处理请求时浪费时间,从而提高效率。


下面是线程池的模拟实现:

    代码实现中并没有实现任务接口,而是把Runnable对象加入到线程池管理器(ThreadPool),然后剩下的事情就由线程池管理器(ThreadPool)来完成了。

[java] view plain copy
 在CODE上查看代码片派生到我的代码片
  1. package com.csu.threadpool;  
  2.    
  3. import java.util.LinkedList;  
  4. import java.util.List;  
  5.    
  6. /**  
  7.  * 线程池类,线程管理器:创建线程,执行任务,销毁线程,获取线程基本信息  
  8.  */  
  9. public final class ThreadPool {  
  10.     // 线程池中默认线程的个数为5  
  11.     private static int worker_num = 5;  
  12.     // 工作线程  
  13.     private WorkThread[] workThreads;  
  14.     // 已处理的任务  
  15.     private static volatile int finished_task = 0;  
  16.     // 任务队列,作为一个缓冲,List线程不安全  
  17.     private List<Runnable> taskQueue = new LinkedList<Runnable>();  
  18.     private static ThreadPool threadPool;  
  19.    
  20.     // 创建具有默认线程个数的线程池  
  21.     private ThreadPool() {  
  22.         this(5);  
  23.     }  
  24.    
  25.     // 创建线程池,worker_num为线程池中工作线程的个数  
  26.     private ThreadPool(int worker_num) {  
  27.         ThreadPool.worker_num = worker_num;  
  28.         workThreads = new WorkThread[worker_num];  
  29.         for (int i = 0; i < worker_num; i++) {  
  30.             workThreads[i] = new WorkThread();  
  31.             workThreads[i].start();// 开启线程池中的线程  
  32.         }  
  33.     }  
  34.    
  35.     // 单态模式,获得一个默认线程个数的线程池  
  36.     public static ThreadPool getThreadPool() {  
  37.         return getThreadPool(ThreadPool.worker_num);  
  38.     }  
  39.    
  40.     // 单态模式,获得一个指定线程个数的线程池,worker_num(>0)为线程池中工作线程的个数  
  41.     // worker_num<=0创建默认的工作线程个数  
  42.     public static ThreadPool getThreadPool(int worker_num1) {  
  43.         if (worker_num1 <= 0)  
  44.             worker_num1 = ThreadPool.worker_num;  
  45.         if (threadPool == null)  
  46.             threadPool = new ThreadPool(worker_num1);  
  47.         return threadPool;  
  48.     }  
  49.    
  50.     // 执行任务,其实只是把任务加入任务队列,什么时候执行由线程池管理器决定  
  51.     public void execute(Runnable tasks) {  
  52.         synchronized (taskQueue) {  
  53.             taskQueue.add(tasks);  
  54.             taskQueue.notify();  
  55.         }  
  56.     }  
  57.    
  58.     // 批量执行任务,其实只是把任务加入任务队列,什么时候执行由线程池管理器决定  
  59.     public void execute(Runnable[] tasks) {  
  60.         synchronized (taskQueue) {  
  61.             for (Runnable t : tasks)  
  62.                 taskQueue.add(t);  
  63.             taskQueue.notify();  
  64.         }  
  65.     }  
  66.    
  67.     // 批量执行任务,其实只是把任务加入任务队列,什么时候执行由线程池管理器决定   
  68.     public void execute(List<Runnable> task) {  
  69.         synchronized (taskQueue) {  
  70.             for (Runnable t : task)  
  71.                 taskQueue.add(t);  
  72.             taskQueue.notify();  
  73.         }  
  74.     }  
  75.    
  76.     // 销毁线程池,该方法保证在所有任务都完成的情况下才销毁所有线程,否则等待任务完成才销毁  
  77.     public void destroy() {  
  78.         while (!taskQueue.isEmpty()) {// 如果还有任务没执行完成,就先睡会吧  
  79.             try {  
  80.                 Thread.sleep(10);  
  81.             } catch (InterruptedException e) {  
  82.                 e.printStackTrace();  
  83.             }  
  84.         }  
  85.         // 工作线程停止工作,且置为null  
  86.         for (int i = 0; i < worker_num; i++) {  
  87.             workThreads[i].stopWorker();  
  88.             workThreads[i] = null;  
  89.         }  
  90.         threadPool=null;  
  91.         taskQueue.clear();// 清空任务队列  
  92.     }  
  93.    
  94.     // 返回工作线程的个数  
  95.     public int getWorkThreadNumber() {  
  96.         return worker_num;  
  97.     }  
  98.    
  99.     // 返回已完成任务的个数,这里的已完成是只出了任务队列的任务个数,可能该任务并没有实际执行完成  
  100.     public int getFinishedTaskNumber() {  
  101.         return finished_task;  
  102.     }  
  103.    
  104.     // 返回任务队列的长度,即还没处理的任务个数  
  105.     public int getWaitTaskNumber() {  
  106.         return taskQueue.size();  
  107.     }  
  108.    
  109.     // 覆盖toString方法,返回线程池信息:工作线程个数和已完成任务个数  
  110.     @Override  
  111.     public String toString() {  
  112.         return "WorkThread number:" + worker_num + "  finished task number:"  
  113.                 + finished_task + "  wait task number:" + getWaitTaskNumber();  
  114.     }  
  115.    
  116.     /**  
  117.      * 内部类,工作线程  
  118.      */  
  119.     private class WorkThread extends Thread {  
  120.         // 该工作线程是否有效,用于结束该工作线程  
  121.         private boolean isRunning = true;  
  122.    
  123.         /*  
  124.          * 关键所在啊,如果任务队列不空,则取出任务执行,若任务队列空,则等待  
  125.          */  
  126.         @Override  
  127.         public void run() {  
  128.             Runnable r = null;  
  129.             while (isRunning) {// 注意,若线程无效则自然结束run方法,该线程就没用了  
  130.                 synchronized (taskQueue) {  
  131.                     while (isRunning && taskQueue.isEmpty()) {// 队列为空  
  132.                         try {  
  133.                             taskQueue.wait(20);  
  134.                         } catch (InterruptedException e) {  
  135.                             e.printStackTrace();  
  136.                         }  
  137.                     }  
  138.                     if (!taskQueue.isEmpty())  
  139.                         r = taskQueue.remove(0);// 取出任务  
  140.                 }  
  141.                 if (r != null) {  
  142.                     r.run();// 执行任务  
  143.                 }  
  144.                 finished_task++;  
  145.                 r = null;  
  146.             }  
  147.         }  
  148.    
  149.         // 停止工作,让该线程自然执行完run方法,自然结束  
  150.         public void stopWorker() {  
  151.             isRunning = false;  
  152.         }  
  153.     }  
  154. }  




测试代码:

[java] view plain copy
 在CODE上查看代码片派生到我的代码片
  1. package com.csu.thread;  
  2.    
  3. //测试线程池  
  4. public class TestThreadPool {  
  5.     public static void main(String[] args) {  
  6.         // 创建3个线程的线程池  
  7.         ThreadPool t = ThreadPool.getThreadPool(3);  
  8.         t.execute(new Runnable[] { new Task(), new Task(), new Task() });  
  9.         t.execute(new Runnable[] { new Task(), new Task(), new Task() });  
  10.         System.out.println(t);  
  11.         t.destroy();// 所有线程都执行完成才destory  
  12.         System.out.println(t);  
  13.     }  
  14.    
  15.     // 任务类  
  16.     static class Task implements Runnable {  
  17.         private static volatile int i = 1;  
  18.    
  19.         @Override  
  20.         public void run() {// 执行任务  
  21.             System.out.println("任务 " + (i++) + " 完成");  
  22.         }  
  23.     }  
  24. }  



运行结果:

WorkThread number:3  finished task number:0  wait task number:6

任务 1 完成

任务 2 完成

任务 3 完成

任务 4 完成

任务 5 完成

任务 6 完成

WorkThread number:3  finished task number:6  wait task number:0


分析:由于并没有任务接口,传入的可以是自定义的任何任务,所以线程池并不能准确的判断该任务是否真正的已经完成(真正完成该任务是这个任务的run方法执行完毕),只能知道该任务已经出了任务队列,正在执行或者已经完成。




二.进一步探讨线程池



2.1 为什么要用线程池?


诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器,这种方式可能是通过网络协议(例如 HTTP、FTP 或 POP)、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达,服务器应用程序中经常出现的情况是:单个任务处理的时间很短而请求的数目却是巨大的。

构建服务器应用程序的一个过于简单的模型应该是:每当一个请求到达就创建一个新线程,然后在新线程中为请求服务。实际上,对于原型开发这种方法工作得很好,但如果试图部署以这种方式运行的服务器应用程序,那么这种方法的严重不足就很明显。每个请求对应一个线程(thread-per-request)方法的不足之一是:为每个请求创建一个新线程的开销很大;为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。

除了创建和销毁线程的开销之外,活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或“切换过度”。为了防止资源不足,服务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。

线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。其好处是,因为在请求到达时线程已经存在,所以无意中也消除了线程创建所带来的延迟。这样,就可以立即为请求服务,使应用程序响应更快。而且,通过适当地调整线程池中的线程数目,也就是当请求的数目超过某个阈值时,就强制其它任何新到的请求一直等待,直到获得一个线程来处理为止,从而可以防止资源不足。


2.2 线程池的替代方案


线程池远不是服务器应用程序内使用多线程的唯一方法。如同上面所提到的,有时,为每个新任务生成一个新线程是十分明智的。然而,如果任务创建过于频繁而任务的平均处理时间过短,那么为每个任务生成一个新线程将会导致性能问题。

另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。AWT 和 Swing 就使用这个模型,在这个模型中有一个 GUI 事件线程,导致用户界面发生变化的所有工作都必须在该线程中执行。然而,由于只有一个 AWT 线程,因此要在 AWT 线程中执行任务可能要花费相当长时间才能完成,这是不可取的。因此,Swing 应用程序经常需要额外的工作线程,用于运行时间很长的、同 UI 有关的任务。

每个任务对应一个线程方法和单个后台线程(single-background-thread)方法在某些情形下都工作得非常理想。每个任务一个线程方法在只有少量运行时间很长的任务时工作得十分好。而只要调度可预见性不是很重要,则单个后台线程方法就工作得十分好,如低优先级后台任务就是这种情况。然而,大多数服务器应用程序都是面向处理大量的短期任务或子任务,因此往往希望具有一种能够以低开销有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。线程池提供了这些优点。


2.3 使用线程池的风险


虽然线程池是构建多线程应用程序的强大机制,但使用它并不是没有风险的。用线程池构建的应用程序容易遭受任何其它多线程应用程序容易遭受的所有并发风险,诸如同步错误和死锁,它还容易遭受特定于线程池的少数其它风险,诸如与池有关的死锁、资源不足和线程泄漏。


2.4 死锁


任何多线程应用程序都有死锁风险。当一组进程或线程中的每一个都在等待一个只有该组中另一个进程才能引起的事件时,我们就说这组进程或线程 死锁了。死锁的最简单情形是:线程 A 持有对象 X 的独占锁,并且在等待对象 Y 的锁,而线程 B 持有对象 Y 的独占锁,却在等待对象 X 的锁。除非有某种方法来打破对锁的等待(Java 锁定不支持这种方法),否则死锁的线程将永远等下去。

虽然任何多线程程序中都有死锁的风险,但线程池却引入了另一种死锁可能,在那种情况下,所有池线程都在执行已阻塞的等待队列中另一任务的执行结果的任务,但这一任务却因为没有未被占用的线程而不能运行。当线程池被用来实现涉及许多交互对象的模拟,被模拟的对象可以相互发送查询,这些查询接下来作为排队的任务执行,查询对象又同步等待着响应时,会发生这种情况。


2.5 资源不足

线程池的一个优点在于:相对于其它替代调度机制(有些我们已经讨论过)而言,它们通常执行得很好。但只有恰当地调整了线程池大小时才是这样的。线程消耗包括内存和其它系统资源在内的大量资源。除了 Thread 对象所需的内存之外,每个线程都需要两个可能很大的执行调用堆栈。除此以外,JVM 可能会为每个 Java 线程创建一个本机线程,这些本机线程将消耗额外的系统资源。最后,虽然线程之间切换的调度开销很小,但如果有很多线程,环境切换也可能严重地影响程序的性能。

如果线程池太大,那么被那些线程消耗的资源可能严重地影响系统性能。在线程之间进行切换将会浪费时间,而且使用超出比您实际需要的线程可能会引起资源匮乏问题,因为池线程正在消耗一些资源,而这些资源可能会被其它任务更有效地利用。除了线程自身所使用的资源以外,服务请求时所做的工作可能需要其它资源,例如 JDBC 连接、套接字或文件。这些也都是有限资源,有太多的并发请求也可能引起失效,例如不能分配 JDBC 连接。


2.6 并发错误


线程池和其它排队机制依靠使用 wait()  notify() 方法,这两个方法都难于使用。如果编码不正确,那么可能丢失通知,导致线程保持空闲状态,尽管队列中有工作要处理。使用这些方法时,必须格外小心;即便是专家也可能在它们上面出错。而最好使用现有的、已经知道能工作的实现,下面的讨论 util.concurrent 包。


2.7 线程泄漏


各种类型的线程池中一个严重的风险是线程泄漏,当从池中除去一个线程以执行一项任务,而在任务完成后该线程却没有返回池时,会发生这种情况。发生线程泄漏的一种情形出现在任务抛出一个 RuntimeException 或一个 Error 时。如果池类没有捕捉到它们,那么线程只会退出而线程池的大小将会永久减少一个。当这种情况发生的次数足够多时,线程池最终就为空,而且系统将停止,因为没有可用的线程来处理任务。

有些任务可能会永远等待某些资源或来自用户的输入,而这些资源又不能保证变得可用,用户可能也已经回家了,诸如此类的任务会永久停止,而这些停止的任务也会引起和线程泄漏同样的问题。如果某个线程被这样一个任务永久地消耗着,那么它实际上就被从池除去了。对于这样的任务,应该要么只给予它们自己的线程,要么只让它们等待有限的时间。


2.8 请求过载


仅仅是请求就压垮了服务器,这种情况是可能的。在这种情形下,我们可能不想将每个到来的请求都排队到我们的工作队列,因为排在队列中等待执行的任务可能会消耗太多的系统资源并引起资源缺乏。在这种情形下决定如何做取决于您自己;在某些情况下,您可以简单地抛弃请求,依靠更高级别的协议稍后重试请求,您也可以用一个指出服务器暂时很忙的响应来拒绝请求。


2.9 有效使用线程池的准则


只要您遵循几条简单的准则,线程池可以成为构建服务器应用程序的极其有效的方法:

· 不要对那些同步等待其它任务结果的任务排队。这可能会导致上面所描述的那种形式的死锁,在那种死锁中,所有线程都被一些任务所占用,这些任务依次等待排队任务的结果,而这些任务又无法执行,因为所有的线程都很忙。

· 在为时间可能很长的操作使用合用的线程时要小心。如果程序必须等待诸如 I/O 完成这样的某个资源,那么请指定最长的等待时间,以及随后是失效还是将任务重新排队以便稍后执行。这样做保证了:通过将某个线程释放给某个可能成功完成的任务,从而将最终取得 某些进展。

· 理解任务。要有效地调整线程池大小,您需要理解正在排队的任务以及它们正在做什么。它们是 CPU 限制的(CPU-bound)吗?它们是 I/O 限制的(I/O-bound)吗?您的答案将影响您如何调整应用程序。如果您有不同的任务类,这些类有着截然不同的特征,那么为不同任务类设置多个工作队列可能会有意义,这样可以相应地调整每个池。


2.10 调整池的大小


调整线程池的大小基本上就是避免两类错误:线程太少或线程太多。幸运的是,对于大多数应用程序来说,太多和太少之间的余地相当宽。

请回忆:在应用程序中使用线程有两个主要优点,尽管在等待诸如 I/O 的慢操作,但允许继续进行处理,并且可以利用多处理器。在运行于具有 N 个处理器机器上的计算限制的应用程序中,在线程数目接近 N 时添加额外的线程可能会改善总处理能力,而在线程数目超过 N 时添加额外的线程将不起作用。事实上,太多的线程甚至会降低性能,因为它会导致额外的环境切换开销。

线程池的最佳大小取决于可用处理器的数目以及工作队列中的任务的性质。若在一个具有 N 个处理器的系统上只有一个工作队列,其中全部是计算性质的任务,在线程池具有 N 或 N+1 个线程时一般会获得最大的 CPU 利用率。

对于那些可能需要等待 I/O 完成的任务(例如,从套接字读取 HTTP 请求的任务),需要让池的大小超过可用处理器的数目,因为并不是所有线程都一直在工作。通过使用概要分析,您可以估计某个典型请求的等待时间(WT)与服务时间(ST)之间的比例。如果我们将这一比例称之为 WT/ST,那么对于一个具有 N 个处理器的系统,需要设置大约 N*(1+WT/ST) 个线程来保持处理器得到充分利用。

处理器利用率不是调整线程池大小过程中的唯一考虑事项。随着线程池的增长,您可能会碰到调度程序、可用内存方面的限制,或者其它系统资源方面的限制,例如套接字、打开的文件句柄或数据库连接等的数目。


2.11 无须编写您自己的池


Doug Lea 编写了一个优秀的并发实用程序开放源码库 util.concurrent ,它包括互斥、信号量、诸如在并发访问下执行得很好的队列和散列表之类集合类以及几个工作队列实现。该包中的 PooledExecutor 类是一种有效的、广泛使用的以工作队列为基础的线程池的正确实现。您无须尝试编写您自己的线程池,这样做容易出错,相反您可以考虑使用 util.concurrent 中的一些实用程序。参阅 参考资料以获取链接和更多信息。

util.concurrent 库也激发了 JSR 166,JSR 166 是一个 Java 社区过程(Java Community Process (JCP))工作组,他们正在打算开发一组包含在 java.util.concurrent 包下的 Java 类库中的并发实用程序,这个包应该用于 Java 开发工具箱 1.5 发行版。


2.12 小结


线程池是组织服务器应用程序的有用工具。它在概念上十分简单,但在实现和使用一个池时,却需要注意几个问题,例如死锁、资源不足和wait()  notify() 的复杂性。如果您发现您的应用程序需要线程池,那么请考虑使用 util.concurrent 中的某个 Executor 类,例如PooledExecutor ,而不用从头开始编写。如果您要自己创建线程来处理生存期很短的任务,那么您绝对应该考虑使用线程池来替代。




java.util.concurrent包中提供的线程池简介



3.1 框架图


java提供的线程池更加强大,相信理解线程池的工作原理,看类库中的线程池就不会感到陌生了。





3.2 比较重要的类


 



ExecutorService

真正的线程池接口。

ScheduledExecutorService

能和Timer/TimerTask类似,解决那些需要任务重复执行的问题。

ThreadPoolExecutor

ExecutorService的默认实现。

ScheduledThreadPoolExecutor

继承ThreadPoolExecutor的ScheduledExecutorService接口实现,周期性任务调度的类实现。

 


说明:线程池中的包括两个类型的线程:核心线程+非核心线程

核心线程数目是固定的,当用ThreadFactory创建核心线程数达到这个固定数目后,便不加增加;线程也不会自动销毁(当然也可以通过allowCoreThreadTimeOut=true,来设置超时销毁)。

当任务数数超过核心线程数时,需要创建非核心线程来处理,非核心线程数目的个数可以指定;非核心线程闲置后一段时间后会自己销毁。


3.3 下面是几种线程池的分类


1、FixedThreadPool:由newFixedThreadPool创建一个核心线程数量为n,非核心线程数为0的线程池。每当提交一个任务就创建一个核心线程,如果核心线程数量达到线程池初始的最大数,则将提交的任务存入到任务队列中。

2、CachedThreadPool:由newCachedThreadPool创建一个核心线程数为0,非核心线程数为Integer.MAX_VALUE的线程池。这种类型的线程池特点是: 

     1) 非核心线程的创建数量几乎没有限制(其实也有限制的,数目为Interger. MAX_VALUE), 这样可灵活的往线程池中添加线程。 

     2) 如果长时间没有往线程池中提交任务,即如果工作线程空闲了指定的时间(默认为1分钟),则该工作线程将自动终止。终止后,如果你又提交了新的任务,则线程池重新创建一个工作线程。

3、ScheduleThreadPool:由newScheduleThreadPool创建一个核心线程数为n,非核心线程为Interger. MAX_VALUE的线程池,而且支持定时的以及周期性的任务执行,类似于Timer。

4、SingleThreadExecutor:由newSingleThreadExecutor创建一个单线程化的Executor,即只创建唯一的工作者线程来执行任务,如果这个线程异常结束,会有另一个取代它,保证顺序执行。单工作线程最大的特点是可保证顺序地执行各个任务,并且在任意给定的时间不会有多个线程是活动的,这使得任务之间不需要处理线程同步问题。


3.4 总结

1) FixedThreadPool是一个典型且优秀的线程池,它具有线程池提高程序效率和节省创建线程时所耗的开销的优点。但是,在线程池空闲时,即线程池中没有可运行任务时,它不会释放工作线程,还会占用一定的系统资源。

2) CachedThreadPool的特点就是在线程池空闲时,即线程池中没有可运行任务时,它会释放工作线程,从而释放工作线程所占用的资源。但是,但当出现新任务时,又要创建一新的工作线程,又要一定的系统开销。并且,在使用CachedThreadPool时,一定要注意控制任务的数量,否则,由于大量线程同时运行,很有会造成系统瘫痪。









参考:

[1] 线程池的原理及实现

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

[3] Java 理论与实践: 线程池与工作队列


0 0