ThreadPoolExecutor 配置

这是ThreadPoolExecutor类前面的一段注释，讲了一些自定义线程池的策略，同时也包含了一些线程池的原理。

1.核心线程数与最大线程数

线程池会根据corePoolSize和maximumPoolSize自动调整线程数
提交任务时，如果当前线程数小于核心线程数则新建线程。
大于core,小于max则只有当任务队列为满的时候会创建线程。
core和max相等的时候就创建了一个线程数目固定的线程池(fixed-size)
max设置为Integer.MAX_VALUE则说明是一个无界的线程池。
可以使用setCorePoolSize和setMaximumPoolSize动态调整线程池

2.按需创建线程池

默认情况下核心线程是在任务提交时才创建的。可以使用prestartCoreThread和prestartAllCoreThread来提前创建线程池。
(如果你配置了一个非空任务队列的话)

3.创建新线程

可以实现ThreadFactory接口（实现类要线程安全）来创建线程，默认使用Executors.defaultThreadFactory,默认实现创建的线程属于同一个ThreadGroup，而且有相同的优先级，线程为非守护线程。
你可以自定义线程池来改变线程名字，线程组，优先级，是否为守护线程等等。

4.Keep-alive times

如果当期线程池的数目大于core，空闲的线程或者超过keepAliveTime时间的线程会被终止。(getKeepAliveTime),这样资源如果不能充分利用可以回收一部分，降低消耗。
如果线程池稍后负载变大则会重新创建线程。该参数同样可以动态调整setKeepAliveTime,如果设置为Long.MAX_VAlUE则不会终止空闲线程，
这种自动调整的策略只针对线程数目大于core的那部分线程。也可以使用
allowCoreThreadTime(boolean)来将该动态调整的策略应用于core线程。（前提是keepAliveTime非零）

5.任务队列

可以使用任意的BlockingQueue来保存和提交任务。
当前线程数少于corePoolSize，线程池一般会选择创建线程而不是将任务放在任务队列中。
当前线程数大于corePoolSize，线程池一般会选择将任务放在任务队列中。
如果一个任务不能入队（任务队列满）则创建线程。如果线程数目超过了maximumPoolSize,则任务会被拒绝。

6.任务等待（排队）策略

6.1 直接提交任务给工作线程

SynchronousQueue会直接将任务提交给工作线程。不会在队列内部保留任务（队列容量为0）。
如果没有线程能马上运行任务则该任务不能提交到任务队列中（相当于任务队列为满），这时候会创建线程。
这种策略避免了线程池停滞（lockups）。（当处理一些有内部依赖的请求时，可能线程池中的大部分线程都在等待一个线程释放锁，这时候就没有线程能处理新的任务了）
这种策略需要搭配一个无界的maximumPoolSize（Long.MAX_VALUE)来避免拒绝新提交的任务。
但是同时又默认的允许在线程池负载较大的时候无限制的创建线程。

6.2 无界队列，一直缓存任务

使用无容量限制的LinkedBlockingQueue，这样当所有的core线程都在忙碌的情况下，新提交的任务会被添加到队列中等待
这种情况下，线程池中的线程数目不会大于corePoolSize(maximumPoolSize这时就不生效了)
这种策略适合在任务之间没有依赖的时候，任务在执行的过程中不会影响其他任务执行。
这种方式可以平滑过多的请求，同时默认了任务队列中可能无限制的缓存任务。

6.3 有界队列

使用容量有限的ArrayBlockingQueue来避免资源无限制的申请。如果设置了无界的maximumPoolSize（Long.MAX_VALUE)。但是这样会对线程池调优产生影响。
队列容量和最大线程数之间会互相影响。
- 使用容量较大的队列和较小的maximumPoolSize会导致低CPU利用率，带来额外的上下文切换。这样就人为的造成了低吞吐量。
- 如果任务经常阻塞（I/O密集型任务）。a system may be able to schedule time for more threads than you otherwise allow.
- 使用较小的队列一般要求更大的线程池大小，这样会提高CPU利用率，但是会带来额外的调度。可能会降低吞吐量。

Queue sizes and maximum pool sizes may be traded off for each other:
- Using large queues and small pools minimizes CPU usage, OS resources, and context-switching overhead, but can lead to artificially low throughput.
- If tasks frequently block (for example if they are I/O bound), a system may be able to schedule time for more threads than you otherwise allow.
- Use of small queues generally requires larger pool sizes, which keeps CPUs busier but may encounter unacceptable scheduling overhead, which also decreases throughput.

6.4 任务拒绝策略

使用execute(Runnable)提交的任务会被拒绝，如果线程池已经关闭，或者线程池使用了有限的线程数目和工作队列容量（而且队列满了）。
任何一种情况该方法都会调用配置的RejectedExecutionHandler中的rejectedExecution(Runnable,ThreadPoolExecutor)方法。

默认提供了4种方式

ThreadPoolExecutor.AbortPolicy会抛出RejectedExecutionException
ThreadPoolExecutor.CallerRunsPolicy会让调用execute()方法的线程去运行任务。
ThreadPoolExecutor.DiscardPolicy直接抛弃任务
ThreadPoolExecutor.DiscardOldestPolicy如果线程池没有关闭，在工作队列头部的任务会被抛弃。

6.5 回调方法

beforeExecute(Thread,Runnable),afterExecute(Runnable,Throwable)在每个任务执行前，后都会被调用。可以用来维护执行环境。比如说重新初始化ThreadLocal，统计信息，或者增加日志
terminated方法可以被重载来添加一些需要在线程池关闭时的操作。
如果回调方法抛出异常，线程池内部的工作线程会终止。

6.6 队列维护

getQueue()方法能拿到工作队列，来增加一些监控和Debug的功能。除了以上的用途，及其不推荐使用该方法来拿到工作队列去做别的事情。
当大量的缓存任务被取消时remove(Runnable)和purge可以用来帮助
清理队列

6.7 Finalization

在程序中没有引用的线程池（垃圾），线程池中的线程不会自动终结。如果你需要保证用户忘记调用shutdown方法时，线程池中的线程也会被自动回收，
你需要设置恰当的keepAliveTime使用一个下界为0的core数目而且设置allowCoreThreadTimeOut(boolean)