J.U.C--ThreadPoolExecutor的配置与使用

ThreadPoolExecutor为Executor提供了基本的实现，这些Executor是由Executors中的静态工厂方法返回的。ThreadPoolExecutor是一种灵活的、稳定的线程池，允许进行各种定制。

1.Executors中的静态工厂方法

其实不管是newCachedThreadPool()、newFixedThreadPool(int nThreads)还是newSingleThreadExecutor() 他们的底层都是根据不同的特性对ThreadPoolExecutor进行了定制。
下面给出源码：

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
}

public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>(),
                                  threadFactory);
}

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>(),
                                  threadFactory);
}

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
    return new ScheduledThreadPoolExecutor(corePoolSize);
}

public static ScheduledExecutorService newScheduledThreadPool(
            int corePoolSize, ThreadFactory threadFactory) {
    return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
}

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>(),
                                threadFactory));
}

从上面的源码我们验证之前的结论，所以对于研究J.U.C的Executor框架，我们需要重点研究的就是ThreadPoolExecutor这个类。

2. ThreadPoolExecutor的类继承图

从上面的类图中我们可以知道，ThreadPoolExecutor基本上是Executor的实现。

3.ThreadPoolExecutor的构造器

构造器中有很多可定制的参数，所以该线程池具有很高的定制性，虽然提供了好几个构造器，但是最终都会调用如下这个构造器：

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
    if (corePoolSize < 0 ||
        maximumPoolSize <= 0 ||
        maximumPoolSize < corePoolSize ||
        keepAliveTime < 0)
        throw new IllegalArgumentException();
    if (workQueue == null || threadFactory == null || handler == null)
        throw new NullPointerException();
    this.corePoolSize = corePoolSize;
    this.maximumPoolSize = maximumPoolSize;
    this.workQueue = workQueue;
    this.keepAliveTime = unit.toNanos(keepAliveTime);
    this.threadFactory = threadFactory;
    this.handler = handler;
}

首先来分析一下构造器的参数（来自JDK文档）

1、corePoolSize - 池中所保存的线程数，包括空闲线程。
2、maximumPoolSize - 池中允许的最大线程数。
3、keepAliveTime - 当线程数大于核心时，此为终止前多余的空闲线程等待新任务的最长时间。
4、unit - keepAliveTime 参数的时间单位。
5、workQueue - 执行前用于保持任务的队列。此队列仅保持由 execute 方法提交的 Runnable 任务。
6、threadFactory - 执行程序创建新线程时使用的工厂。
7、handler - 由于超出线程范围和队列容量而使执行被阻塞时所使用的处理程序。

上面的构造器参数里面最不好理解的就是：corePoolSize 和 maximumPoolSize这两个参数了。所以特别做一个详细的解释：

1、池中线程数小于corePoolSize，新任务都不排队而是直接添加新线程。
2、池中线程数大于等于corePoolSize，workQueue未满，首选将新任务加入workQueue而不是添加新线程。
3、池中线程数大于等于corePoolSize，workQueue已满，但是线程数小于maximumPoolSize，添加新的线程来处理被添加的任务。
4、池中线程数大于等于corePoolSize，workQueue已满，并且线程数大于等于maximumPoolSize，新任务被拒绝，使用handler处理被拒绝的任务。
5、如果设置的 corePoolSize 和 maximumPoolSize 相同，则创建了固定大小的线程池

上面这4条规则非常重要。基本解释清楚了corePoolSize 和 maximumPoolSize这两个参数怎么用。

ThreadPoolExecutor的使用很简单，前面的代码也写过例子了。通过execute(Runnable command)方法来发起一个任务的执行，通过shutDown()方法来对已经提交的任务做一个有效的关闭。尽管线程池很好，但我们要注意JDK API的一段话：
强烈建议程序员使用较为方便的Executors工厂方法Executors.newCachedThreadPool()（无界线程池，可以进行线程自动回收）、Executors.newFixedThreadPool(int)（固定大小线程池）和Executors.newSingleThreadExecutor()（单个后台线程），它们均为大多数使用场景预定义了设置。
所以，跳开对ThreadPoolExecutor的关注（还是那句话，有问题查询JDK API），重点关注一下JDK推荐的Executors。

4.根据ThreadPoolExecutor的构造器分析Executors的静态工厂方法

线程池的重点不是ThreadPoolExecutor怎么用或者是Executors怎么用，而是在合适的场景下使用合适的线程池，所谓”合适的线程池”的意思就是，ThreadPoolExecutor的构造方法传入不同的参数，构造出不同的线程池，以满足使用的需要。
下面来看一下Executors为用户提供的几种线程池：

1、newSingleThreadExecutos() 单线程线程池

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

单线程线程池，那么线程池中运行的肯定是只有一个线程。workQueue选择了无界阻塞队列的LinkedBlockingQueue，那么不管来多少任务都排队，前面一个任务执行完毕，再执行队列中的线程。从这个角度讲，第二个参数maximumPoolSize是没有意义的，因为maximumPoolSize描述的是排队的任务多过workQueue的容量，线程池中最多只能容纳maximumPoolSize个任务，现在workQueue是无界的，也就是说排队的任务永远不会多过workQueue的容量，那maximum其实设置多少都无所谓了。

2、newFixedThreadPool(int nThreads) 固定大小线程池

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

固定大小的线程池和单线程的线程池异曲同工，无非是让线程池中能运行的线程编程了手动指定的nThreads罢了。同样，由于是选择了LinkedBlockingQueue，因此其实第二个参数maximumPoolSize同样也是无意义的.

3、newCachedThreadPool() 无界线程池

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

无界线程池，意思是不管多少任务提交进来，都直接运行。无界线程池采用了同步队列SynchronousQueue，采用这个线程池就没有workQueue容量一说了，只要添加进去的线程就会被拿去用。既然是无界线程池，那线程数肯定没上限，所以以maximumPoolSize为主了，设置为一个近似的无限大Integer.MAX_VALUE。 另外注意一下，单线程线程池和固定大小线程池线程都不会进行自动回收的，也即是说保证提交进来的任务最终都会被处理，但至于什么时候处理，就要看处理能力了。但是无界线程池是设置了回收时间的，由于corePoolSize为0，所以只要60秒没有被用到的线程都会被直接移除。

5. 关于工作队列WorkQueue

上面三种线程池都提到了一个概念，workQueue，也就是排队策略。排队策略描述的是，当前线程大于corePoolSize时，线程以什么样的方式排队等待被运行。

排队有三种策略：直接提交、有界队列、无界队列。

谈谈后两种，JDK使用了无界队列LinkedBlockingQueue作为WorkQueue而不是有界队列ArrayBlockingQueue，尽管后者可以对资源进行控制，但是个人认为，使用有界队列相比无界队列有三个缺点：
1、使用有界队列，corePoolSize、maximumPoolSize两个参数势必要根据实际场景不断调整以求达到一个最佳，这势必给开发带来极大的麻烦，必须经过大量的性能测试。所以干脆就使用无界队列，任务永远添加到队列中，不会溢出，自然maximumPoolSize也没什么用了，只需要根据系统处理能力调整corePoolSize就可以了

2、防止业务突刺。尤其是在Web应用中，某些时候突然大量请求的到来都是很正常的。这时候使用无界队列，不管早晚，至少保证所有任务都能被处理到。但是使用有界队列呢？那些超出maximumPoolSize的任务直接被丢掉了，处理地慢还可以忍受，但是任务直接就不处理了，这似乎有些糟糕

3、不仅仅是corePoolSize和maximumPoolSize需要相互调整，有界队列的队列大小和maximumPoolSize也需要相互折衷，这也是一块比较难以控制和调整的方面

当然，最后还是那句话，就像Comparable和Comparator的对比、synchronized和ReentrantLock，再到这里的无界队列和有界队列的对比，看似都有一个的优点稍微突出一些，但是这绝不是鼓励大家使用一个而不使用另一个，任何东西都需要根据实际情况来，当然在一开始的时候可以重点考虑那些看上去优点明显一点的。

这里有一点需要特别注意的就是，对于阻塞队列的选择不能使用无上限的阻塞队列，因为如果流量太大，会不停往队列里面塞任务，队列里面每个Runable都是要占用内存资源的容易将内存打爆。此外如果消息太多，Runable的运行肯定会有大的延迟，所以一般情况下建议使用同步队列，并合理扩大线程池的数量。

6.四种拒绝策略

所谓拒绝策略之前也提到过了，任务太多，超过maximumPoolSize了怎么把？当然是接不下了，接不下那只有拒绝了。拒绝的时候可以指定拒绝策略，也就是一段处理程序。

决绝策略的父接口是RejectedExecutionHandler，JDK本身在ThreadPoolExecutor里给用户提供了四种拒绝策略，看一下：
1、AbortPolicy
直接抛出一个RejectedExecutionException，这也是JDK默认的拒绝策略

2、CallerRunsPolicy
尝试直接运行被拒绝的任务，如果线程池已经被关闭了，任务就被丢弃了

3、DiscardOldestPolicy
移除最晚的那个没有被处理的任务，然后执行被拒绝的任务。同样，如果线程池已经被关闭了，任务就被丢弃了

4、DiscardPolicy
不能执行的任务将被删除

其实上面的内容大部分都来自JDK文档，所以JDK文档是 非常重要的。