ThreadPoolExecutor

1 核心属性

1.1 int corePoolSize

指该线程池中核心线程数最大值
核心线程：线程池新建线程的时候，如果当前线程总数小于corePoolSize，则新建的是核心线程，如果超过corePoolSize，则新建的是非核心线程。核心线程默认情况下会一直存活在线程池中，即使这个核心线程啥也不干(闲置状态)。
如果指定ThreadPoolExecutor的allowCoreThreadTimeOut这个属性为true，那么核心线程如果不干活(闲置状态)的话，超过一定时间(时长下面参数决定)，就会被销毁掉。

1.2 int maximumPoolSize

指该线程池中线程总数最大值。
线程总数 = 核心线程数 + 非核心线程数。

1.3 long keepAliveTime

指该线程池中非核心线程闲置超时时长
一个非核心线程，如果不干活(闲置状态)的时长超过这个参数所设定的时长，就会被销毁掉，如果设置allowCoreThreadTimeOut = true，则会作用于核心线程。

1.4 BlockingQueue workQueue

指该线程池中的任务队列。
当所有的核心线程都忙碌时，新添加的任务会被添加到这个队列中等待处理；如果队列满了，则新建非核心线程执行任务。
常用的workQueue类型：SynchronousQueue、LinkedBlockingQueue、ArrayBlockingQueue、DelayQueue。

1.4.1 SynchronousQueue

这个队列接收到任务的时候，会直接提交给线程处理，而不保留它，如果所有线程都在忙碌，那就新建一个线程来处理这个任务。此队列通常要求无界 maximumPoolSizes 以避免拒绝新提交的任务。
此时需要注意线程数目与maximumPoolSize的关系，以及线程数目过多而消耗的服务器资源。

1.4.2 LinkedBlockingQueue

这个队列接收到任务的时候，如果当前线程数小于核心线程数，则新建线程(核心线程)处理任务；如果当前线程数等于核心线程数，则进入队列等待。
由于这个队列没有最大值限制，即所有超过核心线程数的任务都将被添加到队列中，这也就导致了maximumPoolSize的设定失效，因为总线程数永远不会超过corePoolSize。

1.4.3 ArrayBlockingQueue

可以限定队列的长度，接收到任务的时候，如果没有达到corePoolSize的值，则新建线程(核心线程)执行任务，如果达到了，则入队等候，如果队列已满，则新建线程(非核心线程)执行任务，又如果总线程数到了maximumPoolSize，并且队列也满了，则发生错误。

1.4.4 DelayQueue

队列内元素必须实现Delayed接口，这就意味着你传进去的任务必须先实现Delayed接口。这个队列接收到任务时，首先先入队，只有达到了指定的延时时间，才会执行任务

1.5 RejectedExecutionHandler handler

线程池无法处理任务时的丢弃策略。

• CallerRunsPolicy

拒绝这个任务，不在ThreadPoolExecutor线程池中的线程中运行，而是调用当前线程池的所在的线程去执行被拒绝的任务。

• AbortPolicy

ThreadPoolExecutor默认的拒绝策略，直接抛出异常。

• DiscardPolicy

线程池默默丢弃这个被拒绝的任务，不会抛出异常。

• DiscardOldestPolicy

会抛弃任务队列中最旧的任务（最先加入队列的任务），再把这个新任务添加到队列中去。

总结
实际上查阅这四种ThreadPoolExecutor线程池自带的拒绝处理器实现，您可以发现CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy处理器针对被拒绝的任务并不是一个很好的处理方式。
CallerRunsPolicy在非线程池以外直接调用任务的run方法，可能会造成线程安全上的问题。
DiscardPolicy默默的忽略掉被拒绝任务，也没有输出日志或者提示，开发人员不会知道线程池的处理过程出现了错误；
DiscardOldestPolicy大部分情况下，默默地抛弃一部分任务都是一件很危险的事情。
通常使用AbortPolicy是最好的，因为抛弃任务时，开发者可以通过日志发现这个问题，并着手处理。

2 执行策略

通常当一个任务被添加进线程池时，总体的执行策略如下，不过具体会根据核心属性定义的值会有少许变动。
如果当前线程数量 < corePoolSize，则新建一个线程(核心线程)执行任务。
如果当前线程数量 >= corePoolSize，则将任务移入队列等待。
如果队列已满，新建线程(非核心线程)执行任务
如果队列已满且总线程数>=maximumPoolSize，就会由RejectedExecutionHandler拒绝任务。

3 常见的线程池

3.1 CachedThreadPool

可缓存线程池

ExecutorService mCachedThreadPool = Executors.newCachedThreadPool();

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

3.2 FixedThreadPool

定长线程池

ExecutorService mFixedThreadPool= Executors.newFixedThreadPool(int nThreads);

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

3.3 SingleThreadPool

只有一个线程的线程池。

ExecutorService mSingleThreadPool = Executors.newSingleThreadPool();

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

3.4 ScheduledThreadPool

按照固定频率执行的线程池。

4 线程池配置

4.1 DB连接池配置

最小连接数=（平均QPS* QPS平均RT +平均TPS* TPS平均RT）／业务机器数
最大连接数=（峰值QPS* QPS平均RT +峰值TPS* TPS平均RT）／业务机器数；如果业务代码中没有另起多线程，那么也可以使用公式：最大连接数= 容器处理请求的线程池大小
复制代码

另外，如果需要，也可以在此公式的基础上预留一些buffer。

4.2 Java线程池配置

4.2.1 CPU密集型任务的线程池配置

因为cpu执行速度非常快，往往切换线程上下文环境所耗费的时间比执行代码花费的时间更长，所以CPU密集型任务的线程数应该尽量保持和CPU核数一致，以减少线程切换带来的性能损耗。

4.2.2 IO密集型任务的线程池配置

IO密集型任务的主要性能瓶颈在于等待IO结果，当遇到任务中存在从DB中读取数据，从缓存中读取数据时，就可以认为是IO密集型任务。一般而言业务系统配置线程池基本上都会采用此模型配置。
假设：an表示系统平均每秒收到的请求数；mn表示系统每秒收到的峰值请求数；at表示每个任务执行的平均时间；more表示预留的buffer；n表示线程池个数；那么线程池可以参考一下公式配置：

核心线程数 = an * at /n * (1+more%)
最大线程数 = mn * at /n * (1+more%)
复制代码