Java从诞生开始就明智地选择内置对多线程的支持。线程作为操作系统调度的最小单元，多个线程能够同时执行将显著提升程序性能，在多核环境中表现得更加明显。但是，过多地创建线程和对线程的不当管理也容易造成问题。
4.1 线程简介
4.1.1 什么是线程
- 现代操作系统在运行一个程序时，会为其创建一个进程。现代操作系统调度的最小单元是线程，也叫轻量级进程（Light Weight Process），在一个进程里可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，并且能够访问共享的内存变量。处理器在这些线程上高速切换，让使用者感觉到这些线程在同时执行。
- 一个Java程序的运行不仅仅是main()方法的运行，而是main线程和多个其他线程的同时运行。
4.1.2 为什么要使用多线程
- 使用多线程的原因：
- （1）更多的处理器核心
- 一个单线程程序在运行时只能使用一个处理器核心，再多的处理器核心加入也无法显著提升该程序的执行效率。相反，如果该程序使用多线程技术，将计算逻辑分配到多个处理器核心上，就会显著减少程序的处理事件，并且随着更多处理核心的加入而变得更有效率。
- （2）更快的响应时间
- 将数据一致性不强的操作派发给其他线程处理（也可以使用消息队列），让相应用户请求的线程能够尽可能快地处理完成，缩短了相应时间，提升了用户体验。
- （3）更好的编程模型
- Java为多线程编程提供了良好、考究并且一直的编程模型，使开发人员能够更加专注于问题的解决，即为所遇到的问题建立合适的模型，一旦开发人员建立好了模型，稍作修改总是能够方便地映射到Java提供的多线程编程模型上。
- （1）更多的处理器核心
4.1.3 线程优先级
- 现代操作系统基本采用时分的形式调度运行的线程，操作系统会分出一个个时间片，线程会分配到若干时间片，当线程的时间片用完了就会发生线程调度，并等待下次分配。线程分配的时间片多少也就决定了线程使用处理器资源的多少，而线程优先级就是决定线程需要多或者少分配一些处理器资源的线程属性。
- 在Java线程中，通过一个整型成员变量priority来控制优先级，优先级的范围从1~10，在线程构建的时候可以通过setPriority(int)方法来修改优先级，默认优先级是5，优先级高的线程分配时间片的数量要多于优先级低的线程。针对频繁阻塞（休眠或者I/O操作）的线程需要设置较高优先级，而偏重计算（需要较多CPU时间或者偏运算）的线程则设置较低的优先级，确保处理器不会比独占。在不同的JVM以及操作系统上，线程规划会存在差异，有些操作系统甚至会忽略对线程优先级的设计。
- 不同优先级输出的没有明显差距，程序正确性不能依赖线程的优先级高低。
- 操作系统可能完全不理会Java线程对于优先级的设定，可以通过就stack查看。
4.1.4 线程的状态
- Java线程在运行的声明周期中可能处于表4-1所示的6种不同的状态，在给定的一个时刻，线程只能处于其中的一个状态：
- 线程创建之后，调用start()方法开始运行。当线程执行外套()方法之后，线程进入等待状态（依靠其他线程的通知或者超时时间到达后回到运行状态）。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到阻塞状态。线程在执行Runnable的run()方法之后将会进入到终止状态。
- 注意：Java将操作系统中的运行和就绪两个状态合并称为运行状态。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块（获取锁）时的状态，但是阻塞在java.concurrent包中Lock接口的线程状态却是等待状态，因为java.concurrent包中Lock接口对于阻塞的实现均使用了LockSupport类中的相关方法。
4.1.5 Daemon线程
- Daemon线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作。当一个Java虚拟机中不存在非Daemon线程的时候，Java虚拟机将会退出。可以通过调用Thread.setDaemon(true)将线程设置为Daemon线程，需要在启动线程之前设置。
- Daemon线程被用作完成支持性工作，但是在Java虚拟机退出时Daemon线程中的finally块并不一定会执行：
4.2 启动和终止线程
4.2.1 构造线程
- 在运行线程之前要构造一个线程对象，线程对象在构造的时候需要提供线程所需要的属性，如线程所属的线程组、线程优先级、是否是Daemon线程等信息。
- 上述过程中，一个新构造的线程对象是由其parent线程来进行空间分配的，而child线程继承了parent是否为Daemon、优先级和加载资源的contextClassLoader以及可继承的ThreadLocal，同时还会分配一个唯一的ID标识这个child线程。至此，一个能够运行的线程对象九初始化好了，在堆内存中等待着运行。
4.2.2 启动线程
- 线程对象在初始化完成之后，调用start()方法就可以启动这个线程。线程start()方法的含义是：当前线程（即parent线程）同步告知Java虚拟机，只要线程规划期空闲，应立即启动调用start()方法的线程。
- 注意：启动一个线程前，最好为这个线程设置线程名称，因为这样在使用jstack分析程序或者进行问题排查时，就会给开发人员提供一些提示，自定义的线程最好能够起个名字。
4.2.3 理解中断
- 中断可以理解为线程的一个标识位属性，它表示一个运行中的线程是否被其他线程进行了中断操作。中断好比其他线程对该线程打了个招呼，其他线程通过调用该线程的interrupt()方法对其进行中断操作。
- 线程通过检查自身是否被中断来进行响应，线程通过方法isInterrupted()来进行判断是否被中断，也可以调用静态方法Thread.interrupted()对当前线程的中断标识位进行复位。如果该线程已经处于终结状态，即使该线程被中断过，在调用该线程对象的isInterrupted()时依旧会返回false。
- 从Java的API中可以看到，许多声明抛出InterruptedException的方法（例如Thread.sleep(long millis)方法）在抛出InterruptedException之前，Java虚拟机会先将该线程的中断标识位清除，然后抛出InterruptedException，此时调用isInterrupted()方法会返回false。
4.2.4 过期的suspend()、resume()和stop()
- suspend()、resume()和stop()方法是过期的，不建议使用的原因：
- 以suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方法在终结一个线程时不会保证线程的资源正常释放，通常是没有给与线程完成资源释放工作的机会，因此会导致程序可能工作再不确定状态下。
- 暂停和恢复操作可以用等待/通知机制来替代。
4.2.5 安全地终止线程
- 中断操作是一种简便的线程间交互方式，这种交互方式最适合用来取消或停止任务。除了中断操作外，还可以利用一个boolean变量来控制是否需要停止任务并终止该线程。
- 示例在执行过程中，main线程通过中断操作和cancel()方法均可使CountThread得以终止。这种通过标识位或者中断操作的方式能够使线程在终止时有机会去清理资源，而不是武断地将线程终止，因此这种终止线程的做法显得更加安全和优雅。
4.3 线程间通信
- 线程开始运行，拥有自己的栈空间，就如同一个脚本一样，按照既定的代码一步一步地执行，直到终止。
4.3.1 volatile和synchronized关键字
- Java支持多个线程同时访问一个对象或者对象的成员变量，由于每个线程可以拥有这个变量的拷贝，所以程序在执行过程中，一个线程看到的变量并不一定是最新的。
- volatile修饰字段（成员变量），就是告知程序对任何该变量的访问均需要从共享内存中获取，而对它的改变必须同步刷新回共享内存，它能保证所有线程对变量访问的可见性。过多的使用volatile是不必要的，它会降低程序执行的效率。
- 关键字synchronized可以修饰方法或者以同步块的形式来进行使用，它主要确保多个线程在同一时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性。
- 上面class信息中，对于同步块的实现使用了monitorenter和monitorexit指令，而同步方法则是依靠方法修饰符上的ACC_SYNCHRONIZED来完成的。无论采用哪种方式，其本质是对一个对象对监视器（monitor）进行获取，而这个获取过程是排他对，也就是同一时刻只能有一个线程获取到由synchronized所保护对象对监视器。
方法的同步并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
- 任意一个对象都拥有自己对监视器，当这个对象由同步块或者这个对象对同步方法调用时，执行方法对线程必须先获取到该对象对监视器才能进入同步块或者同步方法，而没有获取到监视器（执行该方法）到线程将会被阻塞在同步块和同步方法到入口处，进入BLOCKED状态。
- 从图4-2中可以看到，任意线程对Object（Object由synchronized保护）对访问，首先要获得Object对监视器，如果获取失败，线程进入同步队列，线程状态变为BLOCKED。当访问Object当前驱（获得了锁当线程）释放了锁，则释放操作唤醒阻塞在同步队列中当线程，使其重新尝试对监视器的获取。
4.3.2 等待/通知机制
- 一个线程修改了一个对象的值，而另一个线程感知到了变化，然后进行相应的操作，整个过程开始于一个线程，而最终执行又是另一个线程。前者是生产者，后者就是消费者，这种模式隔离了“做上面”（what）和“怎么做”（how），在功能层面上实现了解耦，体系结构上具备了良好的伸缩性，但是在Java语言中如何实现类似的功能呢？
-
简单的办法就是让消费者线程不断的循环检查变量是否符合预期，如下面代码所示，在while循环中设置不满足的条件，如果条件满足则退出while循环，从而完成消费者的工作。
- 上面的伪代码在条件不满足时就睡眠一段时间，这样做的目的是防止过快的“无效”尝试，这种方式看似能够解决实现所需的功能，但是却存在如下问题。
- 难以确保及时性。在睡眠时，基本不消耗处理器资源，但是如果睡得太久，就不能及时发现条件已经变化，也就是及时性难以保证。
- 难以降低开销。如果降低睡眠的时间，比如休眠1毫秒，这个消费者能更加迅速地发现条件变化，但是却可能消耗更多的处理器资源，造成了无端的浪费。
- 以上两个问题，看似矛盾难以调和，但是Java通过内置的等待/通知机制能够很好地解决这个矛盾并实现所需的功能。
- 等待/通知的相关方法是任意Java对象都具备的，因为这些方法被定义在所有对象的 超类java.lang.Object上，方法和描述如表4-2所示。
- 等待通知机制，是指一个线程A调用了对象O的wait()方法进入等待状态，而另一个线程B调用对象O的norify()或者notifyAll()方法，线程A收到通知后从对象O的wait()方法返回，进而执行后续操作。上述两个线程通过对象O来完成交互，而对象上的wait()和notifyAll()的关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。
- 上述第3行和第4行输出的顺序可能会互换，而上述例子主要说明了调用wait()、notify()以及notifyAll()时需要注意的细节，如下：
- 使用wait()、notify()和notifyAll()时需要先对调用对象加锁。
- 调用wait()方法后，线程状态由RUNNING变为WAITING，并将当前对象放置到对象的等待队列。
- notify()或notifyAll()方法调用后，等待线程依旧不会从wait()返回，需要调用notify()或notifyAll()的线程释放锁之后，等待线程才有机会从wait()返回。
- notify()方法将等待队列中的一个等待线程从等待队列中移到同步队列中，而notifyAll()方法则是将等待队列中所有的线程全部移到同步队列，被移动的线程状态由WAITING变为BLOCKED。
- 从wait()方法返回的前提是获得了调用对象的锁。
- 从上述细节中可以看到，等待/通知机制依托于同步机制，其目的就是确保等待线程从wait()方法返回时能够感知到通知线程对变量做出对修改。
- 在图4-3中，WaitThread首先获取了对象对锁，然后调用对象的wait()方法，从而放弃了锁并进入对象的等待队列WaitQueue中，进入等待状态。由于WaitThread释放了对象的锁，NotifyThread随后获取了对象的锁，并调用对象的notify()方法，将WaitThread从WaitQueue释放了锁之后，WaitThread再次获取到锁并从wait()方法返回继续执行。
4.3.3 等待/通知的经典范式
- 从4.3.2节中的WaitNotify示例中可以提炼出等待/通知的经典范式，该范式分为两部分，分别针对等待方（消费者）和通知方（生产者）。
- 等待方遵循如下原则：
- 获取对象的锁。
- 如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。
- 条件满足则执行对应的逻辑。
4.3.4 管道输入/输出流
- 管道输入/输出流和普通的文件输入/输出流或者网络输入/输出流不同之处在于，它主要用于线程之间的数据传输，而传输的媒介为内存。
- 管道输入/输出流主要包括流如下4种具体实现：PipedOutputStream、PipedInputStream、PipedReader和PipedWriter，前两种面向字节，而后两种面向字符。
- 在代码清单4-12所示的例子中，创建流printThread，它用来接受main线程的输入，任何main线程的输入均通过PipedWriter写入，而printThread在另一端通过PipedReader将内容读出并打印。
- 对于Piped类型的流，必须先要进行绑定，也就是调用connect()方法，如果没有将输入/输出流绑定起来，对于该流的访问将会抛出异常。
4.3.5 Thread.join()的使用
- 如果一个线程A执行了thread.join()语句，其含义是：当前线程A等待thread线程终止之后才从thread.join()返回。线程Thread除了提供join()方法之外，还提供了join(long millis)和join(long millis,int nanos)两个具备超时特性的方法。这两个超时方法表示，如果线程thread在给定的超时时间里没有终止，那么将会从该超时方法中返回。
- 从上述输出可以看到，每个线程终止的前提是前驱线程的终止，每个线程等待前驱线程终止后，才从join()方法返回，这里涉及了等待/通知机制（等待前驱线程结束，接收前驱线程结束通知）。
- 当线程终止时，会调用线程自身当notifyAll()方法，会通知所有等待在该线程对象上的线程。join方法的逻辑结构与4.3.3节中描述的等待/通知经典范式一致，即加锁、循环和处理逻辑3个步骤。
4.3.6 ThreadLocal的使用
- ThreadLocal，即线程变量，是一个以ThreadLocal对象为健、任意对象为值的存储结构。这个结构被附带在线程上，也就是说一个线程可以根据一个ThreadLocal对象查询到绑定在这个线程上的一个值。
- 可以通过set(T)方法来设置一个值，在当前线程下再通过get()方法获取到原先设置的值。
- Profiler可以被复用在方法调用耗时统计的功能上，在方法的入口前执行begin()方法，在方法调用后执行end()方法，好处是两个方法的调用不用在一个方法或类中，比如在AOP（面向方面变成）中，可以在方法调用前的切入点执行begin()方法，而在方法调用后的切入点执行end()方法，这样依旧看以获得方法的执行耗时。
4.4 线程应用实例
4.4.1 等待超时模式
- 等待/通知的经典范式（即加锁、条件循环和处理逻辑3个步骤），无法做到超时等待，需要对经典范式做出一个小改动：
- 假设超时时间段是T，那么可以推断出在当前时间now+T之后就会超时。
- 定义如下变量。
- 等待持续时间：REMAINING=T
- 超时时间：FUTURE=now+T
- 这时仅需要wait(REMAINING)即可，在wait(REMAINING)返回之后将执行：REMAINING=FUTURE-now。如果REMAINING小于等于0，表示已经超时，直接退出，否则将继续执行wait(REMAINING)。
- 上述描述等待超时模式对伪代码如下：
- 可以看出，等待超时模式就是在等待/通知范式基础上增加来超时控制，这使得该模式相比原有范式更具有灵活性，因为即使方法执行时间过长，也不会“永久”阻塞调用者，而是会按照调用者对要求“按时”返回。
4.4.2 一个简单的数据库连接池示例
- 连接池对定义：通过构造函数初始化连接对最大上线，通过一个双向队列来维护连接，调用方需要先调用fetchConnection(long)方法来指定在多少毫秒内超时获取连接，当连接使用完成后，需要调用releaseConnection(Connection)方法将连接放回线程池，示例如代码清单4-16所示：
4.4.3 线程池技术及其示例
- 线程池技术预先创建若干数量的线程，并且不能由用户直接对线程对创建进行控制，在这个前提下重复使用固定或较为固定数目对线程来完成任务对执行。这样做对好处是，一方面，消除了频繁创建和消亡线程对系统资源开销，另一方面，面对过量任务对提交能够平缓对劣话化。
4.4.4 一个基于线程池技术的简单Web服务器
- 常见对Java Web服务器，如Tomcat、Jetty，在处理请求对过程中都使用来线程池技术。
- 该Web服务器处理用户请求的时序图如图44所示：
- 随着线程池中线程数量的增加，SimpleHttpServer的吞吐量不断增大，响应时间不断变小，线程池的作用非常明显；
- 线程池中线程数量并不是越多越好，具体的数量需要评估每个任务的处理时间，以及当前计算机的处理器能力和数量。
- 使用的线程锅烧，无法发挥处理器的性能；使用的线程过多，将会增加系统的无故开销，起到相反的作用。
