ThreadPoolExector
核心数据结构
基于线程池的实现原理，下面看一下ThreadPoolExector的核心数据结构。
每一个线程是一个Worker对象。Worker是ThreadPoolExector的内部类，核心数据结构如下：
由定义会发现，Worker继承于AQS，也就是说Worker本身就是一把锁。这把锁有什么用处呢？在接下来分析线程池的关闭、线程执行任务的过程时会了解到。
核心配置参数解释
针对本章最开始提出的线程池实现的几个问题，ThreadPoolExecutor在其构造函数中提供了几个核心配置参数，来配置不同策略的线程池。了解了清楚每个参数的含义，也就明白了线程池的各种不同策略。
上面的各个参数，解释如下：
（1）corePoolSize：在线程池中始终维护的线程个数。
（2）maxPoolSize：在corePooSize已满、队列也满的情况下，扩充线程至此值。
（3）keepAliveTime/TimeUnit：maxPoolSize 中的空闲线程，销毁所需要的时间，总线程数收缩回corePoolSize。
（4）blockingQueue：线程池所用的队列类型。
（5）threadFactory：线程创建工厂，可以自定义，也有一个默认的。
（6）RejectedExecutionHandler：corePoolSize 已满，队列已满，maxPoolSize 已满，最后的拒绝策略。
下面来看这6个配置参数在任务的提交过程中是怎么运作的。在每次往线程池中提交任务的时候，有如下的处理流程：
step1：判断当前线程数是否大于或等于corePoolSize。如果小于，则新建线程执行；如果大于，则进入step2。
step2：判断队列是否已满。如未满，则放入；如已满，则进入step3。
step3：判断当前线程数是否大于或等于maxPoolSize。如果小于，则新建线程执行；如果大于，则进入step4。
step4：根据拒绝策略，拒绝任务。
总结一下：首先判断corePoolSize，其次判断blockingQueue是否已满，接着判断maxPoolSize，最后使用拒绝策略。
很显然，基于这种流程，如果队列是无界的，将永远没有机会走到step 3，也即maxPoolSize没有使用，也一定不会走到step 4。
线程池的优雅关闭
在1.1章节中，讲了线程的优雅关闭，是一个很需要注意的地方。
而线程池的关闭，较之线程的关闭更加复杂。当关闭一个线程池的时候，有的线程还正在执行某个任务，有的调用者正在向线程池提交任务，并且队列中可能还有未执行的任务。因此，关闭过程不可能是瞬时的，而是需要一个平滑的过渡，这就涉及线程池的完整生命周期管理。
1.线程池的生命周期
在JDK 7中，把线程数量（workerCount）和线程池状态（runState）这两个变量打包存储在一个字段里面，即ctl变量。如图6-3所示，最高的3位存储线程池状态，其余29位存储线程个数。而在JDK 6中，这两个变量是分开存储的。
由上面的代码可以看到，ctl变量被拆成两半，最高的3位用来表示线程池的状态，低的29位表示线程的个数。线程池的状态有五种，分别是RUNNING、SHUTDOWN、STOP、TIDYING和TERMINATED。
下面分析状态之间的迁移过程，如图6-4所示。
线程池有两个关闭函数，shutdown（）和shutdownNow（），这两个函数会让线程池切换到不同的状态。在队列为空，线程池也为空之后，进入 TIDYING 状态；最后执行一个钩子函数terminated（），进入TERMINATED状态，线程池才“寿终正寝”。
这里的状态迁移有一个非常关键的特征：从小到大迁移，-1，0，1，2，3，只会从小的状态值往大的状态值迁移，不会逆向迁移。例如，当线程池的状态在TIDYING=2时，接下来只可能迁移到TERMINATED=3，不可能迁移回STOP=1或者其他状态。
除 terminated（）之外，线程池还提供了其他几个钩子函数，这些函数的实现都是空的。如果想实现自己的线程池，可以重写这几个函数。
2.正确关闭线程池的步骤
通过上面的分析，我们知道了线程池的关闭需要一个过程，在调用 shutDown（）或者shutdownNow（）之后，线程池并不会立即关闭，接下来需要调用 awaitTermination 来等待线程池关闭。关闭线程池的正确步骤如下：
awaitTermination（..）函数的内部实现很简单，如下所示。不断循环判断线程池是否到达了最终状态TERMINATED，如果是，就返回；如果不是，则通过termination条件变量阻塞一段时间，“苏醒”之后，继续判断。
3.shutdown（）与shutdownNow（）的区别
下面的代码展示了shutdown（）和shutdownNow（）的区别：
（1）前者不会清空任务队列，会等所有任务执行完成，后者再清空任务队列。
（2）前者只会中断空闲的线程，后者会中断所有线程。
下面看一下在上面的代码里中断空闲线程和中断所有线程的区别。
关键区别点在tryLock（）：一个线程在执行一个任务之前，会先加锁（在6.3.4节会详细讲），这意味着通过是否持有锁，可以判断出线程是否处于空闲状态。tryLock（）如果调用成功，说明线程处于空闲状态，向其发送中断信号；否则不发送。
在上面的代码中，shutdown（） 和shutdownNow（）都调用了tryTerminate（）函数，如下所示。
tryTerminate（）不会强行终止线程池，只是做了一下检测：当workerCount为0，workerQueue为空时，先把状态切换到TIDYING，然后调用钩子函数terminated（）。当钩子函数执行完成时，把状态从 TIDYING 改为 TERMINATED，接着调用 termination.sinaglAll（），通知前面阻塞在awaitTermination的所有调用者线程。
所以，TIDYING和TREMINATED的区别是在二者之间执行了一个钩子函数terminated（），目前是一个空实现。
任务的提交过程分析
提交任务的函数如下：
任务的执行过程分析
在上面的任务提交过程中，可能会开启一个新的Worker，并把任务本身作为firstTask赋给该Worker。但对于一个Worker来说，不是只执行一个任务，而是源源不断地从队列中取任务执行，这是一个不断循环的过程。
下面来看Woker的run（）方法的实现过程。
1.shutdown（）与任务执行过程综合分析
把任务的执行过程和上面的线程池的关闭过程结合起来进行分析，当调用 shutdown（）的时候，可能出现以下几种场景：
场景1：当调用shutdown（）的时候，所有线程都处于空闲状态。
这意味着任务队列一定是空的。此时，所有线程都会阻塞在 getTask（）函数的地方。然后，所有线程都会收到interruptIdleWorkers（）发来的中断信号，getTask（）返回null，所有Worker都会退出while循环，之后执行processWorkerExit。
场景2：当调用shutdown（）的时候，所有线程都处于忙碌状态。
此时，队列可能是空的，也可能是非空的。interruptIdleWorkers（）内部的tryLock调用失败，什么都不会做，所有线程会继续执行自己当前的任务。之后所有线程会执行完队列中的任务，直到队列为空，getTask（）才会返回null。之后，就和场景1一样了，退出while循环。
场景3：当调用shutdown（）的时候，部分线程忙碌，部分线程空闲。有部分线程空闲，说明队列一定是空的，这些线程肯定阻塞在 getTask（）函数的地方。空闲的这些线程会和场景1一样处理，不空闲的线程会和场景2一样处理。
下面看一下getTask（）函数的内部细节。
2.shutdownNow（） 与任务执行过程综合分析
和上面的 shutdown（）类似，只是多了一个环节，即清空任务队列。在第1章中已经讲到，如果一个线程正在执行某个业务代码，即使向它发送中断信号，也没有用，只能等它把代码执行完成。从这个意义上讲，中断空闲线程和中断所有线程的区别并不是很大，除非线程当前刚好阻塞在某个地方。
有兴趣的读者也可以分析在不同场景下调用shutdownNow（）所遇到的情况，此处不再展开。
当一个Worker最终退出的时候，会执行清理工作，代码如下所示。
线程池的4种拒绝策略
在execute（Runnable command）的最后，调用了reject（command）执行拒绝策略，代码如下所示。
RejectedExecutionHandler 是一个接口，定义了四种实现，分别对应四种不同的拒绝策略，默认是AbortPolicy。四种策略的实现代码如下：