类注释
在开始看具体实现之前，我们还是先来读一读类注释，一般会包含作者设计的要点和思考， 很有价值。
使用 Executors 工厂方法
An ExecutorService that executes each submitted task using one of possibly several pooled threads, normally configured using Executors factory methods. Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks. To be useful across a wide range of contexts, this class provides many adjustable parameters and extensibility hooks. However, programmers are urged to use the more convenient Executors factory methods Executors.newCachedThreadPool (unbounded thread pool, with automatic thread reclamation), Executors.newFixedThreadPool (fixed size thread pool) and Executors.newSingleThreadExecutor (single background thread), that preconfigure settings for the most common usage scenarios. Otherwise, use the following guide when manually configuring and tuning this class:
简单翻译一下：
ExecutorService 使用一种线程池来执行提交的任务，通常使用 Executors 工厂方法来配置。 (也就是例如ExecutorService exec = Executors.newCachedThreadPool(); 这样的使用方式) 。
线程池解决了两个不同的问题：执行大量异步任务时候，通常有很好的性能， 因为减少了每个任务调用的开销，它们提供了一种绑定和管理资源(包括执行任务集合时消耗的线程)的方法。
每个 ThreadPoolExecutor 也维护了一些基本的分析，例如任务完成数量。
为了大量上下文的可用，这个类提供许多适应性的参数和扩展钩子。然而， 程序员强烈建议使用更方便的 Executors工厂方法：
Executors.newCachedThreadPool （无界线程池，自动线程回收）
Executors.newFixedThreadPool （固定大小线程池）
Executors.newSingleThreadExecutor （单线程）
他们使用在很多常用的场景， 或者，使用如下指导来手动配置管理这个类：
核心线程数和最大线程池容量
Core and maximum pool sizes A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize) according to the bounds set by corePoolSize (see getCorePoolSize) and maximumPoolSize (see getMaximumPoolSize). When a new task is submitted in method execute(Runnable), and fewer than corePoolSize threads are running, a new thread is created to handle the request, even if other worker threads are idle. If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full. By setting corePoolSize and maximumPoolSize the same, you create a fixed-size thread pool. By setting maximumPoolSize to an essentially unbounded value such as Integer.MAX_VALUE, you allow the pool to accommodate an arbitrary number of concurrent tasks. Most typically, core and maximum pool sizes are set only upon construction, but they may also be changed dynamically using setCorePoolSize and setMaximumPoolSize.
一个线程池根据边界设置 corePoolSize 和 maximumPoolSize 来自动调整线程池尺寸。
- 当一个任务通过 execute方法提交，在跑的线程数量比 corePoolSize 少，一个新的线程就会被创建来处理请求，哪怕其他工作线程是空闲的。
- 如果在跑的线程数比 corePoolSize 多，但是比 maximumPoolSize 少，只有在队列满时候才会创建新线程
通过设置 corePoolSize 和 maximumPoolSize 相同，你就创建了一个固定大小的线程池。 通过设置 maximumPoolSize 为基本上无界的值例如 Integer.MAX_VALUE, 就允许了线程池接受无限并发任务。
最典型的情况是在构造时候设置核心线程和最大线程数，但是也可以通过 setCorePoolSize 和 setMaximumPoolSize方法来动态改变。
按需构造
On-demand construction
By default, even core threads are initially created and started only when new tasks arrive, but this can be overridden dynamically using method prestartCoreThread or prestartAllCoreThreads. You probably want to prestart threads if you construct the pool with a non-empty queue.
Creating new threads New threads are created using a ThreadFactory. If not otherwise specified, a Executors.defaultThreadFactory is used, that creates threads to all be in the same ThreadGroup and with the same NORM_PRIORITY priority and non-daemon status. By supplying a different ThreadFactory, you can alter the thread's name, thread group, priority, daemon status, etc. If a ThreadFactory fails to create a thread when asked by returning null from newThread, the executor will continue, but might not be able to execute any tasks. Threads should possess the "modifyThread" RuntimePermission. If worker threads or other threads using the pool do not possess this permission, service may be degraded: configuration changes may not take effect in a timely manner, and a shutdown pool may remain in a state in which termination is possible but not completed.
默认情况，尽管核心线程只有当新任务到达时才会初始化创建和启动，但是也可以使用方法 prestartCoreThread 或者 prestartAllCoreThreads来动态覆盖。 你使用非空队列构造线程池时候可能想要预启动线程。
创建新线程。 新线程使用一个 ThreadFactory 来创建。或者使用 Executors.defaultThreadFactory ，创建的线程会有相同的组 ThreadGroup 相同的 NORM_PRIORITY 优先级 没有后台状态。
通过提供一个不同的 ThreadFactory, 你可以改变线程名字，线程组，优先级，后台状态，等。如果ThreadFactory 创建线程失败 返回null, 执行器也会继续，但是不会执行任何任务。
线程应该有运行时修改线程权限，服务可能会降级: 配置更改可能无法及时生效, 一个关闭的线程池可能仍然存在关闭了但没完成的任务状态。
Keep-alive times
Keep-alive times
If the pool currently has more than corePoolSize threads, excess threads will be terminated if they have been idle for more than the keepAliveTime (see getKeepAliveTime(TimeUnit)). This provides a means of reducing resource consumption when the pool is not being actively used. If the pool becomes more active later, new threads will be constructed. This parameter can also be changed dynamically using method setKeepAliveTime(long, TimeUnit). Using a value of Long.MAX_VALUE TimeUnit.NANOSECONDS effectively disables idle threads from ever terminating prior to shut down. By default, the keep-alive policy applies only when there are more than corePoolSize threads. But method allowCoreThreadTimeOut(boolean) can be used to apply this time-out policy to core threads as well, so long as the keepAliveTime value is non-zero.
如果池子中有超过 corePoolSize 的线程，当空闲时间超过 keepAliveTime 时就被关闭。 这提供了一种池子资源不活跃时候减少资源消耗的方式。如果之后池子变得更活跃，新线程会被创建。 这个参数也可以动态修改通过 setKeepAliveTime(long, TimeUnit). 使用 Long.MAX_VALUE TimeUnit.NANOSECONDS 可以有效地禁止空闲线程在关闭之前终止。 默认情况， keep-alive策略仅当线程数超过 corePoolSize 的情况生效。 但是方法 allowCoreThreadTimeout(boolean) 可以把这个过期策略应用到核心线程上，此时keepAliveTime值不能是0.
队列
Queuing
Any BlockingQueue may be used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing: If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing. If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread. If a request cannot be queued, a new thread is created unless this would exceed maximumPoolSize, in which case, the task will be rejected. There are three general strategies for queuing: Direct handoffs. A good default choice for a work queue is a SynchronousQueue that hands off tasks to threads without otherwise holding them. Here, an attempt to queue a task will fail if no threads are immediately available to run it, so a new thread will be constructed. This policy avoids lockups when handling sets of requests that might have internal dependencies. Direct handoffs generally require unbounded maximumPoolSizes to avoid rejection of new submitted tasks. This in turn admits the possibility of unbounded thread growth when commands continue to arrive on average faster than they can be processed. Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to wait in the queue when all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed. Bounded queues. A bounded queue (for example, an ArrayBlockingQueue) helps prevent resource exhaustion when used with finite maximumPoolSizes, but can be more difficult to tune and control. 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. 下·
任何BlockingQueue 可能用来转移和持有提交的任务。此队列的使用与池大小调整相互作用：
- 如果运行的线程数比 corePoolSize 小， 执行器总是添加一个新的线程而不是放进队列
- 如果是corePoolSize或者更多数量线程运行，执行器总是会放进队列而不是添加一个线程。
- 如果一个请求不能被队列化，一个新线程就被创建，除非该线程超过了maximumPoolSize, 这种情况任务会被拒绝。
通常有三个队列策略：
- Direct handoffs. 直接交接。 一个好的默认选择是 SynchronousQueue ，它不持有任务直接把它交接给线程。此时如果没有线程可以直接运行任务尝试放到队列，就会失败， 所以会创建一个新线程。此策略避免了当吹了有前后依赖的请求时被锁定的问题。 直接交接通常需要一个无界的 maximumPoolSize来避免拒绝新任务提交。这又反而承认了当线程处理平均比任务到达慢时候线程无限增长的问题。
- Unbounded queues 无界队列。使用无界队列例如LinkedBlockingQueue会当所有核心线程忙碌时候造成任务一直在队列中等待。所以， 不会有超过corePoolSize的线程被创建 （此时maximumPoolSize 的值没有任何作用）。当每个任务完全独立其他任务时候，这种可能是合适的，任务之间互不影响，例如Web page 服务。 虽然这种排队方式在消除请求的瞬时爆发方面很有用，但它承认，当命令平均比处理速度更快地继续到达时，可能会出现无限制的工作队列增长。
- Bounded queues 有界队列。 有界队列（例如 ArrayBlockingQueue） 在使用有限的maximumPoolSize时候帮助避免资源耗尽，但是可能更难调整控制。队列大小和池子最大容量可能需要做出权衡：使用大的队列和小的 pool 能最小化CPU开销，OS资源，上下文切换开销，但是可能导致架构低吞吐量。 如果任务频繁block(例如他们是IO限制)， 一个系统可能需要更多的调度时间。 使用小队列通常需要大的池容量，使得CPU更忙，但是可能遇到不可接受的调度开销，也会降低吞吐量。
Rejected tasks 拒绝任务
New tasks submitted in method execute(Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided:
- In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime RejectedExecutionException upon rejection.
- In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism that will slow down the rate that new tasks are submitted.
- In ThreadPoolExecutor.DiscardPolicy, a task that cannot be executed is simply dropped.
- In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down, the task at the head of the work queue is dropped, and then execution is retried (which can fail again, causing this to be repeated.)
It is possible to define and use other kinds of RejectedExecutionHandler classes. Doing so requires some care especially when policies are designed to work only under particular capacity or queuing policies.
新任务通过方法 execute 提交， 当executor关闭后提交会被拒绝，当 executor使用有限的最大线程数和工作队列容量，就饱和了。在任何一种情况下，执行方法调用RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor) 方法来处理拒绝。提供四种预定义的处理机制：
- 默认 ThreadPoolExecutor.AbortPolicy, handler抛出一个运行时 RejectedExectionException
- ThreadPoolExecutor.CallerRunsPolicy, 调用 execute 本身的线程运行该任务。这提供了一个简单的反馈控制机制，可以减慢新任务的提交速度。
- ThreadPoolExecutor.DiscardPolicy, 一个不能执行的任务，简单丢弃掉。
- ThreadPoolExecutor.DiscardOldPolicy, 如果执行器没有关闭，工作队列头部的任务会被丢弃，之后重试执行(可能再次失败，造成这个重复)
也可以定义使用其他类型的 RejectedExecutionHandler 类。这样做需要特别注意，特别是当策略设计为仅在特定容量或排队策略下工作时。
Hook methods 钩子方法
Hook methods
This class provides protected overridable beforeExecute(Thread, Runnable) and afterExecute(Runnable, Throwable) methods that are called before and after execution of each task. These can be used to manipulate the execution environment; for example, reinitializing ThreadLocals, gathering statistics, or adding log entries. Additionally, method terminated can be overridden to perform any special processing that needs to be done once the Executor has fully terminated. If hook or callback methods throw exceptions, internal worker threads may in turn fail and abruptly terminate.
这个类提供 保护的可覆盖的 beforeExecute(Thread, Runnable) 和 afterExecute(Runnable, Throwable) 方法在每个任务执行前或执行后的调用。 这些可以被用来控制执行环境；例如，重新初始化 ThreadLocals, 分析，或者添加日志。 更多的，方法 terminated 可以被重写来提供任意需要Executor完全停止时候的操作。 如果钩子或回调方法抛出异常，如果钩子或回调方法抛出异常，则内部工作线程可能反过来失败并突然终止
队列维护
Queue maintenance
Method getQueue() allows access to the work queue for purposes of monitoring and debugging. Use of this method for any other purpose is strongly discouraged. Two supplied methods, remove(Runnable) and purge are available to assist in storage reclamation when large numbers of queued tasks become cancelled.
getQueue() 方法允许操作工作队列来监控或者Debug. 使用这个方法来做其他期望的事是强烈不鼓励的。两个提供的方法： remote(Runnable) 和 purge 当大量的队列任务需要取消时，可以协助进行存储回收。
最终
Finalization
A pool that is no longer referenced in a program AND has no remaining threads will be shutdown automatically. If you would like to ensure that unreferenced pools are reclaimed even if users forget to call shutdown, then you must arrange that unused threads eventually die, by setting appropriate keep-alive times, using a lower bound of zero core threads and/or setting allowCoreThreadTimeOut(boolean).
一个线程池不再被别的程序引用而且不再持有线程，将会被自动关闭。如果你想确保在忘了调用shutdown时候线程池也能回收， 你必须安排未使用的线程最终死亡，通过设置恰当的 keep-alive 时间， 使用低界限的0个核心线程 并且/或者 设置 allowCoreThreadTimeOut(boolean)
扩展例子
Extension example. Most extensions of this class override one or more of the protected hook methods. For example, here is a subclass that adds a simple pause/resume feature:
大多数扩展需要覆盖一个或更多保护的钩子方法。例如，以下是一个子类，添加一个简单的暂停/恢复功能。
class PausableThreadPoolExecutor extends ThreadPoolExecutor {
private boolean isPaused;
private ReentrantLock pauseLock = new ReentrantLock();
private Condition unpaused = pauseLock.newCondition();
public PausableThreadPoolExecutor(...) { super(...); }
protected void beforeExecute(Thread t, Runnable r) {
super.beforeExecute(t, r);
pauseLock.lock();
try {
while (isPaused) unpaused.await();
} catch (InterruptedException ie) {
t.interrupt();
} finally {
pauseLock.unlock();
}
}
public void pause() {
pauseLock.lock();
try {
isPaused = true;
} finally {
pauseLock.unlock();
}
}
public void resume() {
pauseLock.lock();
try {
isPaused = false;
unpaused.signalAll();
} finally {
pauseLock.unlock();
}
}
}
