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

【 tulaoshi.com - 编程语言 】

　　贴在我们多线程 Java 编程论坛上最常见的问题之一是怎样创建线程池？。几乎在每个服务器应用程序中都会出现线程池和工作队列问题。本文中，Brian Goetz 探讨了线程池的动机、一些基本实现和调优技术以及一些要避免的常见危险。为什么要用线程池？

　　诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程

　　我们通常想要的是同一组固定的工作线程相结合的工作队列，它使用 wait() 和 notify() 来通知等待线程新的工作已经到达了。该工作队列通常被实现成具有相关监视器对象的某种链表。清单 1 显示了简单的合用工作队列的示例。尽管 Thread API 没有对使用 Runnable 接口强加特殊要求，但使用 Runnable 对象队列的这种模式是调度程序和工作队列的公共约定。

　　清单 1. 具有线程池的工作队列

public class WorkQueue{　　private final int nThreads;　　private final PoolWorker[] threads;　　private final LinkedList queue;　　public WorkQueue(int nThreads)　　{　　　　this.nThreads = nThreads;　　　　queue = new LinkedList();　　　　threads = new PoolWorker[nThreads];　　　　for (int i=0; inThreads; i++) {　　　　　　threads[i] = new PoolWorker();　　　　　　threads[i].start();　　　　}　　}　　public void execute(Runnable r) {　　　　synchronized(queue) {　　　　　　queue.addLast(r);　　　　　　queue.notify();　　　　}　　}　　private class PoolWorker extends Thread {　　　　public void run() {　　　　　　Runnable r;　　　　　　while (true) {　　　　　　　　synchronized(queue) {　　　　　　　　　　while (queue.isEmpty()) {　　　　　　　　　　　　try　　　　　　　　　　　　{　　　　　　　　　　　　　　queue.wait();　　　　　　　　　　　　}　　　　　　　　　　　　catch (InterruptedException ignored)　　　　　　　　　　　　{　　　　　　　　　　　　}　　　　　　　　　　}　　　　　　　　　　r = (Runnable) queue.removeFirst();　　　　　　　　}　　　　　　　　// If we don't catch RuntimeException,　　　　　　　　// the pool could leak threads　　　　　　　　try {　　　　　　　　　　r.run();　　　　　　　　}　　　　　　　　catch (RuntimeException e) {　　　　　　　　　　// You might want to log something here　　　　　　　　}　　　　　　}　　　　}　　}}

　　您可能已经注意到了清单 1 中的实现使用的是 notify() 而不是 notifyAll() 。大多数专家建议使用 notifyAll() 而不是 notify() ，而且理由很充分：使用 notify() 具有难以捉摸的风险，只有在某些特定条件下使用该方法才是合适的。另一方面，如果使用得当， notify() 具有比 notifyAll() 更可取的性能特征；特别是， notify() 引起的环境切换要少得多，这一点在服务器应用程序中是很重要的。

　　清单 1 中的示例工作队列满足了安全使用 notify() 的需求。因此，请继续，在您的程序中使用它，但在其它情形下使用 notify() 时请格外小心。

　　使用线程池的风险

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

　　死锁

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

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

　　资源不足

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