线程池与工作队列

 读IBM Development 中国 的文章的笔记整理.

 

 

为什么要用线程池？

           构建服务器应用程序的一个过于简单的模型应该是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上，如果部署在生产环境, 那么这种方法的严重不足就很明显。

          每个请求对应一个线程（thread-pre-request ）方 法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用 户请求的时间和资源更多。

除了创建和销毁线程的开销之外，活动的线程也消耗系统资源.

 

          线程池 为线程生命周期开销问题和资源不足问题提供了解决方案。

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

 

 

线程池的替代方案：

     线程池远不是服务器应用程序内使用多线程的唯一方法。

     另一个常见的线程模型是为某一类型的任务分配一个后台线程与任务队列。
     AWT 和 Swing 就使用这个模型，在这个模型中有一个 GUI 事件线程，导致用户界面发生变化的所有工作都必须在该线程中执行。然而，由于只有一个 AWT 线程，因此要在 AWT 线程中执行任务可能要花费相当长时间才能完成，这是不可取的。因此，Swing 应用程序经常需要额外的工作线程，用于运行时间很长的、同 UI 有关的任务。
          每个任务对应一个线程方法 和 单个后台线程 （single-background-thread ）方法在某些情形下都工作得非常理想。每个任务一个线程方法 在只有少量运行时间很长的任务时工作得十分好。而只要调度可预见性不是很重要，则单个后台线程方法就工作得十分好，如低优先级后台任务. 然而，大多数服务器应用程序都是面向处理大量的短期任务或子任务 ，因此往往希望具有一种能够以低开销有效地处理这些任务的机制以及一些资源管理和定时可预见 性的措施 。线程池提供了这些优点。

 

 

        我们可以轻易地实现一个线程池类，

       其中（1 ）客户机类等待一个可用线程、（2 ）将任务传递给该线程以便执行、（3 ）然后在任务完成时将线程归还给池，

 

设计线程池类容易出现的问题：

    如在池为空时，会发生什么呢？

试图向池线程传递任务的调用者都会发现池为空，在调用者等待一个可用的池线程时，它的线程将阻塞。我们之所以要使用后台线程 的原因之一常常是为了防止正在提交的线程被阻塞。完全堵住调用者，如在线程池的“明显的”实现的情况，可以杜绝我们试图解决的问题的发生。

 

 

 

工作队列:

同一组固定的工作线程相结合的工作队列.

它使用 wait() 和 notify() 来通知等待线程新的工作已经到达了. 该工作队列通常被实现成具有相关监视器对象的某种链表

 

 

 

 

 

 

package threadpoolandqueue;

import java.util.LinkedList;

/**
 * 工作队列
 * @author root
 * OS:Ubuntu 9.04
 * Date:2010-6-23
 */
public class WorkQueue {
	private final int nThreads;
	private final PoolWorker[] threads;
	private final LinkedList queue;
	
	public WorkQueue(int threadCount) {
		this.nThreads=threadCount;
		queue=new LinkedList();
		threads=new PoolWorker[nThreads];
		for(int i=0;i<nThreads;i++){
			threads[i]=new PoolWorker();
			threads[i].start();
		}
	}
	
	public void execute(Runnable task){
		synchronized (queue) {
			queue.addLast(task);
			queue.notify();
		}
	}
	
	private class PoolWorker extends Thread{
		public void run() {
			Runnable r;
			while(true){
				synchronized (queue) {
					while(queue.isEmpty()){
						try {
							queue.wait();
						} catch (InterruptedException e) {
							
						}
					}
					r=(Runnable)queue.remove();
				}
				try {
					r.run();
				} catch (RuntimeException e) {
					//log something.
				}
			}
		}
	}
}

 

     TestCase:

package threadpoolandqueue;

import java.util.LinkedList;

import junit.framework.TestCase;

public class TestWorkQueue extends TestCase {
	public void testWorkQueue(){
		WorkQueue queue=new WorkQueue(10);
		//获取10个线程， 每个线程从100～1 数数.
		for(int i=0;i<10;i++){
			Runnable task=new TestTask(100);
			queue.execute(task);
		}
	}
	
	private class TestTask implements Runnable{
		private int number;
		public TestTask(int num) {
			this.number=num;
		}
		public void run() {
			while(number>0){
				System.out.println(--number);
			}
		}
		
	}
}

 

 

 

 

线程池的风险：

• 死锁：

任何多线程应用程序都有死锁风险。

死锁的最简单情形是：

线程 A 持有对象 X 的独占锁，并且在等待对象 Y 的锁，

而线程 B 持有对象 Y 的独占锁，却在等待对象 X 的锁。

除非有某种方法来打破对锁的等待（Java 锁定不支持这种方法），否则死锁的线程将永远等下去。

 

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

• 资源不足：

               线程池的一个优点在于：相对于其它替代调度机制而言，它们通常执行得很好。 但只有恰当地调整了线程池大小时 才是这样的。 线程消耗包括内存和其它系统资源在内的大量资源。除了 Thread 对象所需的内存之外，

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

• 并发错误：

        线程池和其它排队机制依靠使用 wait() 和 notify() 方法，这两个方法都难于使用。

• 线程泄露：

        各种类型的线程池中一个严重的风险是线程泄漏 ，当从池中除去一个线程以执行一项任务，而在任务完成后该线程却没有返回池时，会发生这种情况。 发生线程泄漏的一种情形出现在任务抛出一个 RuntimeException 或一个 Error 时。如果池类没有捕捉到它们，那么线程只会退出而线程池的大小将会永久减少一个。当这种情况发生的次数足够多时，线程池最终就为空，而且系统将停止，因为没有可用的线程来处理任务。
        有些任务可能会永远等待某些资源或来自用户的输入，而这些资源又不能保证变得可用，用户可能也已经回家了，诸如此类的任务会永久停止，而这些停止的任务也 会引起和线程泄漏同样的问题。如果某个线程被这样一个任务永久地消耗着，那么它实际上就被从池除去了。对于这样的任务，应该要么只给予它们自己的线程，要么只让它们等待有限的时间。

• 请求过载

        仅仅是请求就压垮了服务器。这样的情况，我们可能不想每个到来的请求都排队到我们的工作队列，因为排在队列中等待执行的任务可能会消耗太多的系统资源并引起资源缺乏。

 

 

有效使用线程池的准则：

• 不要对那些同步等待结果的任务排队，可能会导致死锁。在那种死锁当中，所有线程都被一些任务所占用，这些任务依次等待排队任务的结果，而这些任务又无法执行，因为所有线程都很忙。

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

• 理解任务。 要有效地调整线程池大小，您需要理解正在排队的任务以及它们正在做什么。它们是CPU 限制的？ Io 限制的？

 

 

 

 

调整线程池的大小：

       调整线程池的大小基本上就是避免两类错误：线程太少或线程太多。
       线程池最佳大小取决于可用处理器的数目以及工作队列中任务的性质。
              若在一个具有N 个处理器的系统上只有一个工作队列，其中全部是计算性质的任务，在线程池具有N 或N ＋1 个线程时一般会获得最大的CPU 利用率。
       对于那些可能需要等待I ／O 完成的任务（比如，从套接字读取HTTP 请求的任务），需要让池的大小超过可用处理器的数目，因为并不是所有线程都一直工作。可以估计某个典型请求的等待时间（WT ）与服务时间（ST ）之间的比例。如果我们将这一比例称之为 WT/ST ，那么对于一个具有 N 个处理器的系统，需要设置大约 N*(1+WT/ST) 个线程来保持处理器得到充分利用。
              处理器利用率不是调整线程池大小过程中的唯一考虑事项。随着线程池的增长，您可能会碰到调度程序、可用内存方面的限制，或者其它系统资源方面的限制，例如套接字、打开的文件句柄或数据库连接等的数目。