java线程简介、启动终止线程、线程间通信及示例

目录

线程简介

什么是线程

为什么要使用多线程

线程优先级

线程的状态

Daemon线程

启动和终止线程

构造线程

启动线程

理解中断

过期的suspend()、resume()和stop()

安全地终止线程

线程间通信

volatile和synchronized关键字

等待／通知机制

等待／通知的经典范式

管道输入／输出流

Thread.join()的使用

ThreadLocal的使用

线程应用实例

等待超时模式

一个简单的数据库连接池示例

线程池技术及其示例

一个基于线程池技术的简单Web服务器

---

线程简介

什么是线程

现代操作系统在运行一个程序时，会为其创建一个进程。例如，启动一个Java程序，操作 系统就会创建一个Java进程。现代橾作系统调度的最小单元是线程，也叫轻量级进程(Light Weight Process) , 在一个进程里可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局 部变量等属性，并且能够访问共享的内存变量。处理器在这些线程上高速切换，让使用者感觉 到这些线程在同时执行。

一个Java程序从main()方法开始执行，然后按照既定的代码逻辑执行，看似没有其他线程 参与，但实际上Java程序天生就是多线程程序，因为执行main()方法的是一个名称为main的线 程。下面使用JMX来查看一个普通的Java程序包含哪些线程，如代码清单

可以看到一个Java程序的运行不仅仅是main()方法的运行，而是main线程和多个其他线 程的同时运行。

为什么要使用多线程

执行一个简单的'Hello,World!", 却启动了那么多的无关“线程，是不是把简单的问题复 杂化了？当然不是因为正确使用多线程，总是能够给开发人员带来显著的好处，而使用多线 程的原因主要有以下几点。

(1)更多的处理器核心

随着处理器上的核心数量越来越多，以及超线程技术的广泛运用，现在大多数计算机都 比以往更加擅长并行计算，而处理器性能的提升方式，也从更高的主频向更多的核心发展。如 何利用好处理器上的多个核心也成了现在的主要问题。

线程是大多数操作系统调度的基本单元，一个程序作为一个进程来运行，程序运行过程 中能够创建多个线程，而一个线程在一个时刻只能运行在一个处理器核心上。试想一下，一个 单线程程序在运行时只能使用一个处理器核心，那么再多的处理器核心加入也无法显著提升 该程序的执行效率。相反，如果该程序使用多线程技术，将计算逻辑分配到多个处理器核心 上，就会显著减少程序的处理时间，并且随着更多处理器核心的加入而变得更有效率。

(2)更快的响应时间

有时我们会编写一些较为复杂的代码（这里的复杂不是说复杂的算法，而是复杂的业务逻 辑），例如，一笔订单的创建，它包括插入订单数据、生成订单快照、发送邮件通知卖家和记录 货品销售数量等。用户从单击“订购”按钮开始，就要等待这些橾作全部完成才能看到订购成 功的结果。但是这么多业务操作，如何能够让其更快地完成呢？

在上面的场景中，可以使用多线程技术，即将数据一致性不强的操作派发给其他线程处 理（也可以使用消息队列），如生成订单快照、发送邮件等。这样做的好处是响应用户请求的线 程能够尽可能快地处理完成，缩短了响应时间，提升了用户体验。

(3)更好的编程模型

Java为多线程编程提供了良好、考究并且一致的编程模型，使开发人员能够更加专注于问 题的解决，即为所遇到的问题建立合适的模型，而不是绞尽脑汁地考虑如何将其多线程化。一 旦开发人员建立好了模型，稍做修改总是能够方便地映射到Java提供的多线程编程模型上。

线程优先级

现代操作系统基本采用时分的形式调度运行的线程，操作系统会分出一个个时间片，线 程会分配到若干时间片，当线程的时间片用完了就会发生线程调度，并等待浩下次分配。线程 分配到的时间片多少也就决定了线程使用处理器资涌的多少，而线程优先级就是决定线程需 要多或者少分配一些处理器资源的线程属性。

在Java线程中，通过一个整型成员变量priority来控制优先级，优先级的范围从1~10, 在线 程构建的时候可以通过setPriority(int)方法来修改优先级，默认优先级是5, 优先级高的线程分 配时间片的数量要多于优先级低的线程。设置线程优先级时，针对频繁阻塞（休眠或者IO操 作）的线程需要设置较高优先级，而偏重计算（需要较多CPU时间或者偏运算）的线程则设置较 低的优先级，确保处理器不会被独占。在不同的JVM以及操作系统上，线程规划会存在差异， 有些操作系统甚至会忽略对线程优先级的设定。

可以看到线程优先级没有生效，优先级1和优先级10的Job计数的结果非常相近， 没有明显差距。这表示程序正确性不能依赖线程的优先级高低。

注意：线程优先级不能作为程序正确性的依赖，因为橾作系统可以完全不用理会Java 线程对于优先级的设定。笔者的环境为： Mac OS X 10.10, Java版本为1.7.0一71, 经过笔者验证 该环境下所有Java线程优先级均为5(通过jstack查看），对线程优先级的设置会被忽略。另外， 尝试在Ubuntu 14. 04环境下运行该示例，输出结果也表示该环境忽略了线程优先级的设置。

线程的状态

Java线程在运行的生命周期中可能处于表所示的6种不同的状态，在给定的一个时刻， 线程只能处于其中的一个状态。

由图中可以看到，线程创建之后，调用start()方法开始运行。当线程执行wait()方法之 后，线程进入等待状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状 态，而超时等待状态相当于在等待状态的基础上增加了超时限制，也就是超时时间到达时将 会返回到运行状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到阻塞 状态。线程在执行Runnable的run()方法之后将会进入到终止状态。

注意：Java将操作系统中的运行和就绪两个状态合并称为运行状态。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块（获取锁）时的状态，但是阻塞在java.concurrent包中Lock接口的线程状态却是等待状态，因为Java.concurrent包中Lock接口对于 阻塞的实现均使用了LockSupport类中的相关方法。

Daemon线程

Daemon线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作。这 意味着当一个Java虚拟机中不存在非Daemon线程的时候，Java虚拟机将会退出。可以通过调 用Thread. setDaemon(true)将线程设置为Daemon线程。

注意：Daemo咄属性需要在启动线程之前设置，不能在启动线程之后设置。

Daemon线程被用作完成支待性工作，但是在Java虚拟机退出时Daemon线程中的finally块 并不一定会执行。

注意：在构建Daemon线程时，不能依靠finally块中的内容来确保执行关闭或清理资源的逻辑。

启动和终止线程

构造线程

在运行线程之前首先要构造一个线程对象，线程对象在构造的时候需要提供线程所需要 的属性，如线程所属的线程组、线程优先级、是否是Daemon线程等信息。代码清单所示的 代码摘自j ava.lang. Thread中对线程进行初始化的部分。

在上述过程中，一个新构造的线程对象是由其parent线程来进行空间分配的，而child线程 继承了parent是否为:Daemon、优先级和加载资源的contextClassLoader以及可继承的 ThreadLocal, 同时还会分配一个唯一的ID来标识这个child线程。至此，一个能够运行的线程对 象就初始化好了，在堆内存中等待着运行。

启动线程

线程对象在初始化完成之后，调用start()方法就可以启动这个线程。

线程start()方法的含义 是：当前线程（即parent线程）同步告知Java虚拟机，只要线程规划器空闲，应立即启动调用 start()方法的线程（即有空闲时，就调用线程的run方法）。

注意：启动一个线程前最好为这个线程设置线程名称，因为这样在使用jstack分析程序或者进行问题排查时，就会给开发人员提供一些提示，自定义的线程最好能够起个名字。

理解中断

中断可以理解为线程的一个标识位属性，它表示一个运行中的线程是否被其他线程进行 了中断操作。中断好比其他线程对该线程打了个招呼，其他线程通过调用该线程的interrupt() 方法对其进行中断橾作。

线程通过检查自身是否被中断来进行响应，线程通过方法interrupted()来进行判断是否 被中断，也可以调用静态方法Thread. interrupted()对当前线程的中断标识位进行复位。如果该 线程已经处于终结状态，即使该线程被中断过，在调用该线程对象的interrupted()时依旧会返 回false。

从Java的API中可以看到，许多声明抛出InterruptedExcepti on的方法（例如Thread.sleep(long millis)方法）这些方法在抛出InterruptedException之前，Java虚拟机会先将该线程的中断标识位 清除，然后抛出InterruptedExcepti on, 此时调用is Interrupted()方法将会返回false。

在代码清单所示的例子中，首先创建了两个线程，Sleep Thread和BusyThread, 前者不停 地睡眠，后者一直运行，然后对这两个线程分别进行中断操作，观察二者的中断标识位。

从结果可以看出，抛出InterruptedExcepti on的线程Sleep Thread, 其中断标识位被清除了， 而一直忙碌运作的线程BusyThread, 中断标识位没有被清除。

过期的suspend()、resume()和stop()

大家对于CD机肯定不会陌生，如果把它播放音乐比作一个线程的运作，那么对音乐播放 做出的暂停、恢复和停止操作对应在线程Thread的API就是suspend()、resume()和stop()。

在代码清单所示的例子中，创建了一个线程Print Thread, 它以1秒的频率进行打印，而 主线程对其进行暂停、恢复和停止操作。

在执行过程中，Print Thread运行了3秒，随后被暂停，3秒后恢复，最后经过3秒被终止。

通过示例的输出可以看到，suspend()、resume()和stop()方法完成了线程的暂停、恢复和终 止工作，而且非常“人性化”。但是这些API是过期的也就是不建议使用的。

不建议使用的原因主要有：以suspend()方法为例，在调用后，线程不会释放已经占有的资 源（比如锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方法在终结 一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资源释放工作的机会， 因此会导致程序可能工作在不确定状态下。

（就是让线程自己处理中断的情况，别人告诉他们可以中断，自己处理这种情况，才是安全的）

注意：正因为suspend()、resume()和stop()方法带来的副作用这些方法才被标注为不建 议使用的过期方法，而暂停和恢复操作可以用后面提到的等待／通知机制来替代。

安全地终止线程

中断状态是线程的一个标识位，而中断操作是一种简便的线程间交互 方式，而这种交互方式最适合用来取消或停止任务。除了中断以外，还可以利用一个boolean变 量来控制是否需要停止任务并终止该线程。

在代码清单所示的例子中，创建了一个线程Count Thread, 它不断地进行变量累加，而 主线程尝试对其进行中断操作和停止操作。

示例在执行过程中，main线程通过中断橾作和cancel()方法均可使Count Thread得以终止。

这种通过标识位或者中断橾作的方式能够使线程在终止时有机会去清理资源，而不是武断地 将线程停止，因此这种终止线程的做法显得更加安全和优雅。

线程间通信

线程开始运行，拥有自己的栈空间，就如同一个脚本一样，按照既定的代码一步一步地执 行，直到终止。但是，每个运行中的线程，如果仅仅是孤立地运行，那么没有一点儿价值，或者 说价值很少，如果多个线程能够相互配合完成工作，这将会带来巨大的价值。

volatile和synchronized关键字

Java支持多个线程同时访问一个对象或者对象的成员变量，由于每个线程可以拥有这个 变量的拷贝（虽然对象以及成员变量分配的内存是在共享内存中的，但是每个执行的线程还是 可以拥有一份拷贝，这样做的目的是加速程序的执行，这是现代多核处理器的一个显著特 性），所以程序在执行过程中，一个线程看到的变量并不一定是最新的。

关键字volatile可以用来修饰字段（成员变量），就是告知程序任何对该变量的访问均需要 从共享内存中获取而对它的改变必须同步刷新回共享内存，它能保证所有线程对变量访问 的可见性。

举个例子，定义一个表示程序是否运行的成员变量boolean on=true, 那么另一个线程可能 对它执行关闭动作(on=false), 这里涉及多个线程对变量的访问，因此需要将其定义成为

volatile boolean on=true, 这样其他线程对它进行改变时，可以让所有线程感知到变化，因为所 有对on变量的访问和修改都需要以共享内存为准。但是，过多地使用volatile是不必要的，因为 它会降低程序执行的效率。

关键字synchronized可以修饰方法或者以同步块的形式来进行使用，它主要确保多个线程 在同一个时刻只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性 和排他性。

在代码清单所示的例子中，使用了同步块和同步方法，通过使用javap工具查看生成 的class文件信息来分析synchronized关键字的实现细节，示例如下。

在Synchronized.class同级目录执行javap一v Synchronized.class, 部分相关输出如下所示：

上面class信息中，对于同步块的实现使用了moni to renter和monitorexit指令，而同步方法则 是依靠方法修饰符上的ACC一SYNCHRONIZED来完成的。无论采用哪种方式，其本质是对一 个对象的监视器(monitor)进行获取，而这个获取过程是排他的，也就是同一时刻只能有一个 线程获取到由synchronized所保护对象的监视器。

任意一个对象都拥有自己的监视器，当这个对象由同步块或者这个对象的同步方法调用 时，执行方法的线程必须先获取到该对象的监视器才能进入同步块或者同步方法，而没有获 取到监视器（执行该方法）的线程将会被阻塞在同步块和同步方法的入口处，进入BLOCKED 状态。

图描述了对象、对象的监视器、同步队列和执行线程之间的关系。

从图中可以看到，任意线程对Object (Object由synchronized保护）的访问，首先要获得 Object的监视器。如果获取失败，线程进入同步队列，线程状态变为BLOCKED。当访问Object 的前驱（获得了锁的线程）释放了锁，则该释放操作唤醒阻塞在同步队列中的线程，使其重新 尝试对监视器的获取。

等待／通知机制

一个线程修改了一个对象的值，而另一个线程感知到了变化，然后进行相应的操作，整个 过程开始于一个线程，而最终执行又是另一个线程。前者是生产者，后者就是消费者，这种模 式隔离了“做什么"(what)和怎么做"(How), 在功能层面上实现了解耦，体系结构上具备了良 好的伸缩性，但是在Java语言中如何实现类似的功能呢？

简单的办法是让消费者线程不断地循环检查变量是否符合预期，如下面代码所示，在 while循环中设置不满足的条件，如果条件满足则退出while循环，从而完成消费者的工作。

上面这段伪代码在条件不满足时就睡眠一段时间，这样做的目的是防止过快的“无效＂尝 试，这种方式看似能够解实现所需的功能，但是却存在如下问题。

1)难以确保及时性。在睡眠时，基本不消耗处理器资源，但是如果睡得过久，就不能及时 发现条件已经变化，也就是及时性难以保证。

2)难以降低开销。如果降低睡眠的时间比如休眠1毫秒，这样消费者能更加迅速地发现 条件变化，但是却可能消耗更多的处理器资源，造成了无端的浪费。

以上两个问题，看似矛盾难以调和，但是Java通过内置的等待／通知机制能够很好地解决 这个矛盾并实现所需的功能。

等待／通知的相关方法是任意Java对象都具备的，因为这些方法被定义在所有对象的超类 java.lang. Object上，方法和描述如表

等待／通知机制，是指一个线程A调用了对象的wait()方法进入等待状态，而另一个线程B 调用了对象的notify()或者notifyAll()方法，线程A收到通知后从对象0的wait()方法返回，进而 执行后续操作。上述两个线程通过对象O来完成交互，而对象上的wait()和notify/notify All()的 关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。

在代码清单所示的例子中，创建了两个线程WaitThread和NotifyThread, 前者检查 flag值是否为false, 如果符合要求，进行后续操作，否则在lock上等待，后者在睡眠了一段时间 后对lock行通知，示例如下所示。

上述第3行和第4行输出的顺序可能会互换，而上述例子主要说明了调用wait()、notify()以 及notify All()时需要注意的细节，如下。

1)使用wait()、notify()和notify All()时需要先对调用对象加锁。

2)调用wait()方法后，线程状态由RUNNING变为WAITING, 并将当前线程放置到对象的 等待队列。

3) notify()或notify All()方法调用后，等待线程依旧不会从wait()返回，需要调用notify()或 notifAll()的线程释放锁之后，等待线程才有机会从wait()返回。

4)notify()方法将等待队列中的一个等待线程从等待队列中移到同步队列中，而notify All() 方法则是将等待队列中所有的线程全部移到同步队列，被移动的线程状态由WAITING变为BLOCKED。

5)从wait()方法返回的前提是获得了调用对象的锁。

从上述细节中可以看到，等待／通知机制依托于同步机制，其目的就是确保等待线程从 waitO方法返回时能够感知到通知线程对变量做出的修改。

在图中，WaitThread首先获取了对象的锁，然后调用对象的wait()方法，从而放弃了锁 并进入了对象的等待队列WaitQueue中，进入等待状态。由于WaitThread释放了对象的锁，NotifyThread随后获取了对象的锁，并调用对象的notify()方法，将WaitThread从WaitQueue移到 SynchronizedQueue中，此时WaitThread的状态变为阻塞状态。NotifyThread释放了锁之后， WaitThread再次获取到锁并从wait()方法返回继续执行。

等待／通知的经典范式

WaitNotify示例中可以提炼出等待／通知的经典范式，该范式分为两部分，分 别针对等待方（消费者）和通知方（生产者）。

等待方遵循如下原则。

1)获取对象的锁。

2)如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。

3)条件满足则执行对应的逻辑。

对应的伪代码如下。

通知方遵循如下原则。

1)获得对象的锁。

2)改变条件。

3)通知所有等待在对象上的线程。

对应的伪代码如下。

管道输入／输出流

管道输入／输出流和普通的文件输入／输出流或者网络输入／输出流不同之处在于，它主要 用于线程之间的数据传输，而传输的媒介为内存。

管道输入／输出流主要包括了如下4种具体实现： PipedOutputStream、Pi pedlnputS tream、 Pi pedReader和PipedWriter, 前两种面向字节，而后两种面向字符。

在代码清单所示的例子中，创建了print Thread, 它用来接受main线程的输入，任何 main线程的输入均通过PipedWriter写入，而print Thread在另一端通过PipedReader将内容读出 并打印。

对于Piped类型的流，必须先要进行绑定，也就是调用connect()方法，如果没有将输入／输 出流绑定起来，对于该流的访问将会抛出异常。

Thread.join()的使用

如果一个线程A执行了thread.join()语句，其含义是：当前线程A等待thread线程终止之后才 从thread.join()返回。线程Thread除了提供join()方法之外，还提供了join(long millis)和join(long millis,int nanos)两个具备超时特性的方法。这两个超时方法表示，如果线程thread在给定的超时 时间里没有终止，那么将会从该超时方法中返回。

在代码清单所示的例子中，创建了10个线程，编号0~9, 每个线程调用前一个线程的 join()方法，也就是线程0结束了，线程l才能从join()方法中返回，而线程0需要等待main线程结 束。

从上述输出可以看到，每个线程终止的前提是前驱线程的终止，每个线程等待前驱线程 终止后，才从join()方法返回，这里涉及了等待／通知机制（等待前驱线程结束，接收前驱线程结 束通知）。

代码清单4-14是中Thread.j oin()方法的源码（进行了部分调整）。

当线程终止时，会调用线程自身的notify All()方法，会通知所有等待在该线程对象上的线 程。可以看到join()方法的逻辑结构与等待／通知经典范式一致，即加锁、循环 和处理逻辑3个步骤。

ThreadLocal的使用

ThreadLocal, 即线程变量，是一个以ThreadLocal对象为键、任意对象为值的存储结构。这 个结构被附带在线程上，也就是说一个线程可以根据一个ThreadLocal对象查询到绑定在这个 线程上的一个值。

可以通过set(T)方法来设置一个值，在当前线程下再通过get()方法获取到原先设置的值。

在代码清单所示的例子中，构建了一个常用的Profiler类，它具有begin()和end()两个 方法，而end()方法返回从begin()方法调用开始到end()方法被调用时的时间差，单位是毫秒。

Profiler可以被复用在方法调用耗时统计的功能上，在方法的入口前执行begin()方法，在 方法调用后执行end()方法，好处是两个方法的调用不用在一个方法或者类中，比如在AOP(面 向方面编程）中，可以在方法调用前的切入点执行begin()方法，而在方法调用后的切入点执行 end()方法，这样依旧可以获得方法的执行耗时。

线程应用实例

等待超时模式

开发人员经常会遇到这样的方法调用场景：调用一个方法时等待一段时间(一般来说是给 定一个时间段），如果该方法能够在给定的时间段之内得到结果，那么将结果立刻返回，反之， 超时返回默认结果。

前面的章节介绍了等待／通知的经典范式，即加锁、条件循环和处理逻辑3个步骤，而这种 范式无法做到超时等待。而超时等待的加入，只需要对经典范式做出非常小的改动，改动内容 如下所示。

假设超时时间段是T, 那么可以推断出在当前时间NOW+T之后就会超时。 定义如下变量。

·等待持续时间： REMAINING=T。

·超时时间： FUTURE=now+ T。

这时仅需要wait(REMAINING)即可，在wait(REMAINING)返回之后会将执行：

REMAINING=FUTURE一now。如果REMAINING小于等于0, 表示已经超时，直接退出，否则将 继续执行wait(REMAINING)。

上述描述等待超时模式的伪代码如下。

可以看出，等待超时模式就是在等待／通知范式基础上增加了超时控制，这使得该模式相 比原有范式更具有灵活性，因为即使方法执行时间过长，也不会“永久＂阻塞调用者，而是会按 照调用者的要求”按时“返回。

一个简单的数据库连接池示例

我们使用等待超时模式来构造一个简单的数据库连接池，在示例中模拟从连接池中获 取、使用和释放连接的过程，而客户端获取连接的过程被设定为等待超时的模式，也就是在 1000毫秒内如果无法获取到可用连接，将会返回给客户端一个null。设定连接池的大小为10 个，然后通过调节客户端的线程数来模拟无法获取连接的场景。

首先看一下连接池的定义。它通过构造函数初始化连接的最大上限，通过一个双向队列 来维护连接，调用方需要先调用fetchConnecti on(long)方法来指定在多少毫秒内超时获取连接， 当连接使用完成后，需要调用releaseConnecti on(Connection)方法将连接放回线程池，示例如代 码清单所示。

由于j ava.sql. Connection是一个接口，最终的实现是由数据库驱动提供方来实现的，考虑到 只是个示例，我们通过动态代理构造了一个Connection, 该Connection的代理实现仅仅是在 commit()方法调用时休眠100毫秒，示例如

下面通过一个示例来测试简易数据库连接池的工作情况，模拟客户端CannectianRunner获 取、使用、最后释放连接的过程，当它使用时连接将会增加获取到连接的数量，反之，将会增 加未获取到连接的数量，示例如

上述示例中使用了CountDownLatch来确保Connecti onR.unnerThread能够同时开始执行，并 且在全部结束之后，才使main线程从等待状态中返回。当前设定的场景是10个线程同时运行 获取连接池(10个连接）中的连接，通过调节线程数量来观察未获取到连接的情况。线程数、总 获取次数、获取到的数量、未获取到的数量以及未获取到的比率，如

从表中的数据统计可以看出，在资源一定的情况下（连接池中的10个连接），随着客户端 线程的逐步增加，客户端出现超时无法获取连接的比率不断升高。虽然客户端线程在这种超 时获取的模式下会出现连接无法获取的情况，但是它能够保证客户端线程不会一直挂在连接 获取的操作上，而是按时“返回，并告知客户端连接获取出现问题，是系统的一种自我保护机 制。数据库连接池的设计也可以复用到其他的资源获取的场景，针对昂贵资源（比如数据库连 接）的获取都应该加以超时限制。

线程池技术及其示例

对于服务端的程序，经常面对的是客户端传入的短小（执行时间短、工作内容较为单一） 任务，需要服务端快速处理并返回结果。如果服务端每次接受到一个任务，创建一个线程，然 后进行执行，这在原型阶段是个不错的选择，但是面对成千上万的任务递交进服务器时，如果 还是采用一个任务一个线程的方式，那么将会创建数以万记的线程，这不是一个好的选择。因 为这会使操作系统频繁的进行线程上下文切换，无故增加系统的负载，而线程的创建和消亡 都是需要耗费系统资源的，也无疑浪费了系统资源。

线程池技术能够很好地解决这个问题，它预先创建了若干数量的线程，并且不能由用户 直接对线程的创建进行控制，在这个前提下重复使用固定或较为固定数目的线程来完成任务 的执行。这样做的好处是，一方面，消除了频繁创建和消亡线程的系统资源开销，另一方面， 面对过量任务的提交能够平缓的劣化。

客户端可以通过execute(Job)方法将Job提交入线程池执行，而客户端自身不用等待Job的 执行完成。除了execute(Job)方法以外，线程池接口提供了增大／减少工作者线程以及关闭线程 池的方法。这里工作者线程代表着一个重复执行Job的线程，而每个由客户端提交的Job都将进入到一个工作队列中等待工作者线程的处理。

从线程池的实现可以看到，当客户端调用e:xecute(Job)方法时，会不断地向任务列表jobs中 添加Job, 而每个工作者线程会不断地从jobs上取出一个Job进行执行，当jobs为空时，工作者线 程进入等待状态。

添加一个Job后，对工作队列jobs调用了其notify()方法，而不是notify All()方法，因为能够 确定有工作者线程被唤醒，这时使用notify()方法将会比notify All()方法获得更小的开销（避免 将等待队列中的线程全部移动到阻塞队列中）。

可以看到线程池的本质就是使用了一个线程安全的工作队列连接工作者线程和客户端 线程，客户端线程将任务放入工作队列后便返回，而工作者线程则不断地从工作队列上取出 工作并执行。当工作队列为空时，所有的工作者线程均等待在工作队列上，当有客户端提交了 一个任务之后会通知任意一个工作者线程，随着大量的任务被提交，更多的工作者线程会被 唤醒。

一个基于线程池技术的简单Web服务器

目前的浏览器都支持多线程访问，比如说在请求一个HTML页面的时候，页面中包含的图 片资涌、样式资涌会被浏览器发起并发的获取，这样用户就不会遇到一直等到一个图片完全 下载完成才能继续查看文字内容的尴尬情况。

如果Web服务器是单线程的多线程的浏览器也没有用武之地，因为服务端还是一个请求 一个请求的顺序处理。因此，大部分Web服务器都是支持并发访问的。常用的Java Web服务器， 如Tomcat、Jetty, 在其处理请求的过程中都使用到了线程池技术。

下面通过使用前一节中的线程池来构造一个简单的Web服务器，这个Web服务器用来处理 HTTP请求，目前只能处理简单的文本和JPG图片内容。这个Web服务器使用main线程不断地接 受客户端Socket的连接，将连接以及请求提交给线程池处理，这样使得Web服务器能够同时处 理多个客户端请求，示例如代码

SimplelittpServer在建立了与客户端的连接之后，并不会处理客户端的请求， 而是将其包装成HttpRequestliandler并交由线程池处理。在线程池中的Worker处理客户端请求 的同时，SimplelittpServer能够继续完成后续客户端连接的建立，不会阻塞后续客户端的请求。