本文详细介绍了Java中的ThreadPoolExecutor线程池工作原理，包括其参数配置、任务执行流程、线程和任务队列管理机制等内容。
概述：
ThreadPoolExecutor -> AbstractExecutorService =>ExecutorService =>Executor.
ThreadPoolExecutor 解决了两个不同的问题：1，通过减少任务调用开销来改善执行大量异步任务时的性能问题；2，提供资源约束与管理，包括线程。另外还有一些统计功能，比如已完成任务个数等。
为了使用于不同的上下文环境，ThreadPoolExecutor提供了很多可调整的参数和钩子方法， 但是官方仍然推荐编程者使用更为便捷的 Executors 的工厂方法，这些方法根据不同场景进行了配置，可以满足大部分需求：
newCachedThreadPool() (无大小限制线程池，线程自动回收),
newFixedThreadPool(int) (线程池大小固定)
以及 newSingleThreadExecutor() (单个后台线程).
当你需要直接使用ThreadPoolExecutor 时， 可参考一下指南：
Core and maximum pool sizes
ThreadPoolExecutor可以根据corePoolSize和maximumPoolSize自动调整线程池的大小(分别通过getPoolSize() 和getCorePoolSize()进行查看) . 当有新的任务提交时会调用execute(Runnable), 如果当前正在运行的线程数小于corePoolSize，新的线程会被创建来执行新提交的任务，即使当前有空闲线程。如果当前运行的线程数大于corePoolSize但是小于maximumPoolSize, 同时任务队列（queue）已经满了的话，一个新的线程会被创建来执行任务. 设置corePoolSize 和 maximumPoolSize 相等时, 相当于创建了一个固定大小的线程池. 如果设置 maximumPoolSize 为一个无限值比如Integer.MAX_VALUE, 那么该池中将允许有任意数量的并发任务. 一般情况下 corePoolSize和 maximumPoolSize 在构造时传入, 不过也可以通过setCorePoolSize(int)和setMaximumPoolSize(int)来动态设定.On-demand construction
默认情况下核心线程（core threads）只在有新任务到达时才会初始化和启动, 不过可以通过覆写
prestartCoreThread()或者prestartAllCoreThreads()方法来改变这种行为.Creating new threads
默认通过
ThreadFactory创建新的线程. 它们将有相同的ThreadGroup，具有NORM_PRIORITY优先级并且是非守护线程. 你可以提供不同的ThreadFactory 来改变线程的名字、组别、优先级、守护状态等. 如果ThreadFactory创建线程失败，该executor 将继续运行，但是不能再执行任何任务.Keep-alive times
如果当前线程池中线程的数量已经多于corePoolSize, 那么额外的线程如果处于idle状态超过时间 keepAlive(查看
getKeepAliveTime(TimeUnit))将会被强行终止. 这样当线程池的使用比较紧张时可以有效地减少资源消耗.当线程池再次紧张时，新的（额外）线程还会被创建. keepAlive时间可以通过setKeepAliveTime(long, TimeUnit)方法来设置 .使用Long.MAX_VALUENANOSECONDS可以使处于idle状态的线程不被终止，直到ThreadPoolExecutor被关闭 （shut down）. 默认情况下， keep-alive 策略只在当前线程数量多于 corePoolSize 时起作用.但是可以通过方法allowCoreThreadTimeOut(boolean)设置是否将这样的超时策略同时应用于core Threads, 前提是 keepAliveTime 是非零的.Queuing
任何
BlockingQueue都可以用来调度和存储提交的任务. 任务队列的使用和线程池大小的改变有依赖关系:如果当前线程数量小于coreThreadSize, Executor 会优先选择创建新线程来执行任务，而不是将任务存入队列.
如果有多于或等于corePoolSize个线程在运行, Executor 会将新的任务请求入队，而不是创建新的线程.
如果任务请求不能入队，新线程会被创建，但是要求线程数量不超过 maximumPoolSize, 否则任务请求会被拒绝(rejected).
队列有三种广泛使用的策略:
直接传递(Direct handoffs). 一个不错的默认选择是使用同步队列(
SynchronousQueue), 将任务直接交给线程处理而不是存储起来. 如果没有线程及时处理，任务也不能被成功存储，所以新的线程会被创建. 这种方法在处理一组有互相依赖的任务时避免了繁复的查找. 直接传递策略一般要求一个无界的线程池（unbounded maximumPoolSizes ），这样才能避免提交的任务被拒绝. 这种做法存在一个缺点，当任务到达速度超过线程对任务的处理速度是，线程数量会无限制的增长.无界队列(Unbounded queues). 如果当前的corePoolSize个线程都处于忙状态时，使用无界队列 (比如
LinkedBlockingQueue,不预先设置容量) 会把新的任务缓存在队列里. 这样executor里不会有多于corePoolSize 个线程. ( 这样maximumPoolSize 就不再起作用了.) 无界队列策略适用于任务相互独立的情况，各个任务不会影响彼此的执行， 比如 web page 服务器处理页面请求. 虽然这种方法可以使爆发式请求得到平滑的处理，但是当任务处理速度较慢时，可能造成任务队列的无限制增长.有界对类(Bounded queues). 有界队列(比如
ArrayBlockingQueue) 是直接传递和无界队列的一个平衡，通过设置一个有限的maximumPoolSizes值，可以防止资源的过度消耗， 但是这种方式更难调整和控制. 任务队列大小和最大线程池大小需要互相折中: 使用较大的队列和较小的线程池可以减少CPU、系统资源 以及上下文切换开销, 但是会影响吞吐量. 当任务频繁阻塞时 (比如等待I/O),这种做法会对系统的调度造成负面影响 . 如果使用较小的任务队列就要求有较大的线程池, 这样可以使CPU充分利用，但是会引发过度的调度开销，从而也会映像吞吐量.
Rejected tasks
如果executor已经关闭，或者executor使用了有界的线程池和有界的任务队列并且都已饱和，那么通过方法 execute(Runnable) 提交的新任务会被拒绝。 无论哪种情况， execute 方法都会调用 RejectedExecutionHandler的 rejectedExecution(Runnable, ThreadPoolExecutor) 方法. RejectedExecutionHandler有四中预设的处理:
默认使用
ThreadPoolExecutor.AbortPolicy, 当有任务被拒绝时会抛出运行时异常：RejectedExecutionException.ThreadPoolExecutor.CallerRunsPolicy, 这种策略在调用execute方法的线程（即提交任务的线程）中运行任务 . 这种策略提供了一个简单的返回机制来使降低新任务的提交频率。ThreadPoolExecutor.DiscardPolicy, 这种策略只是简单的丢弃新任务，不做任何反馈处理.ThreadPoolExecutor.DiscardOldestPolicy, 如果 executor 尚未关闭, 任务队列首部的任务会被丢弃, 然后重试提交任务 (如果再次失败，还要重复这一过程.)
定义并使用其他的处理策略也是可以的. 但是要格外注意特定的工作场景下的队列容量和队列管理策略。
Hook methods
ThreadPoolExecutor提供了可覆写的beforeExecute(Thread, Runnable) 和 afterExecute(Runnable, Throwable)方法， 这些方法在每次执行任务前、后分别调用，可用来操作执行环境，比如重新初始化线程本地变量（ThreadLocals）,收集统计信息或者添加日志项 . 另外，还可以覆写 terminated() 方法在Executor完全终止前做一些特殊的处理工作.
如果钩子方法或回调方法抛出异常，内部的工作线程也可能会失败并异常终止。
Queue maintenance
方法 getQueue() 提供了访问queue的途径，从而对queue进行监视和调试，不推荐用于其他目的. 当有大量入队的任务被取消时，另外两个方法, remove(Runnable) and purge() 可用于存储资源的回收.
Finalization
线程池不再被程序引用 并且 没有任何剩余的线程在运行时，线程池会被自动关闭 (shutdown ). 如果你想确保未被引用的线程池被回收， 即使用户忘记调用 shutdown(), 那么你必须使未被使用的线程最能够终止, 可以通过设置适当的 keep-alive 时间, 使用下限为0的核心线程数并且/或者 设置allowCoreThreadTimeOut(boolean)来实现.
下面看一下提交一个任务到执行的具体过程：
/*
* Proceed in 3 steps:
*
* 1. If fewer than corePoolSize threads are running, try to
* start a new thread with the given command as its first
* task. The call to addWorker atomically checks runState and
* workerCount, and so prevents false alarms that would add
* threads when it shouldn't, by returning false.
*
* 2. If a task can be successfully queued, then we still need
* to double-check whether we should have added a thread
* (because existing ones died since last checking) or that
* the pool shut down since entry into this method. So we
* recheck state and if necessary roll back the enqueuing if
* stopped, or start a new thread if there are none.
*
* 3. If we cannot queue task, then we try to add a new
* thread. If it fails, we know we are shut down or saturated
* and so reject the task.
*/
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
//scene 1
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
// scene 2
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
// scene 3
else if (!addWorker(command, false))
reject(command);
}从注释里可以看到任务被添加时有三种情况，scene 1 和 scene 3 都容易理解， 我们看第二种， addWorker(null, false):
addworker, 这里的firstTask 是null， 但是worker里的thread还是启动了， 为什么？
private boolean addWorker(Runnable firstTask, boolean core) {
...
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
...
workers.add(w);
...
workerAdded = true;
}
} finally {
mainLock.unlock();
}
if (workerAdded) {
t.start();
workerStarted = true;
}
}
} finally {
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}Worker也是一个runnable， 这里的线程启动运行的是Worker的run方法，里面又调用了runWorker 方法：
我们看下 worker的构造：
private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable
{
...
/** Delegates main run loop to outer runWorker */
public void run() {
runWorker(this);
}
...
}下面的runWorker方法中注意while loop， 当前的worker如果有task就执行，否则调用getTask 从workQueue中取一个来执行，执行完会继续去取， 这里就体现了“线程池”的概念， 并不是一个任务一个线程，而是在线程数量达到限定的数量，同时任务数比较多被放入缓存队列的时候， 一个线程有可能执行多个任务。
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
boolean completedAbruptly = true;
try {
while (task != null || (task = getTask()) != null) {
w.lock();
...
try {
beforeExecute(wt, task);
Throwable thrown = null;
try {
task.run();
} catch (RuntimeException x) {
...
} finally {
afterExecute(task, thrown);
}
} finally {
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}看一下getTask方法：
这里有一个无限的for loop， 直到从workQueue取到一个任务，或者等待超时，或者当前的executor被关闭
private Runnable getTask() {
boolean timedOut = false; // Did the last poll() time out?
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
int wc = workerCountOf(c);
// Are workers subject to culling?
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}从上面的过程可以看出， 通过addWorker(null, false /true)提交的任务虽然是null， 但是仍然会启动一个线程去workQueue中等待或取得一个任务。
扫一扫
98
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
