我们起头今天的主题：线程池。线程池是面试中必问的陈腔滥调文，我将涉及到到的问题分为3大类：
根底利用线程池是什么？为什么要利用线程池？Executor框架是什么？Java供给了哪些线程池？实现原理线程池的底层原理是若何实现的？创建线程池的参数有哪些？线程池中的线程是什么时间创建的?系统设想若何合理的设置线程池的大小？若是办事器宕机，怎么处置队列中的使命？希望今天的内容可以帮你解答以上的问题。
Tips：
本文利用Java 11源码停止阐发；文章会在源码中添加正文，关键内容会有零丁的阐发。池化思惟在你的编程生活生计中，必然碰到过各类各样的“池”，如：数据库毗连池，常量池，以及今天的线程池。无一破例，它们都是借助池化思惟来办理计算机中的资本。
维基百科中是如许描述“池化”的：
In resource management, pooling is the grouping together of resources (assets, equipment, PErsonnel, effort, etc.) for the purposes of maximizing advantage or minimizing risk to the users. The term is used in finance, computing and equipment management.
“池化”指的是将资本会聚到一路，以阐扬优势或降低风险。
接着来看维基百科中对“池”的描述：
In computer science, a pool is a collection of resources that are kept, in memory, ready to use, rather than the memory acquired on use and the memory released afterwards.A pool client requests a resource from the pool and performs desired operations on the returned resource. When the client finishes its use of the resource, it is returned to the pool rather than released and lost.
计算机科学中的“池”，是内存中保留资本的集合，创建资本以备利用，停用时收受接管，而不是利用时创建，停用时丢弃。客户端从池中恳求资本，并施行操做，当不再利用资本时，将资本偿还到池中，而不是释放或丢弃。
为什么要利用“池”？起首"池"是资本的集合，通过“池”能够实现对资本的同一办理；
其次，“池”内存放已经创建并初始化的资本，利用时间接从“池”内获取，跳过了创建及初始化的过程，进步了响应速度；
最初，资本利用完成后偿还到“池”中，而非丢弃或销毁，进步资本的操纵率。
线程池池化思惟的引入是为领会决资本办理中碰到的问题，而线程池恰是借助池化思惟实现的线程办理东西。那么线程池能够帮忙我们处理哪些现实的问题呢？
最间接的是控造线程的创建，不加以限造的创建线程会耗尽系统资本。不信的话你能够尝尝下面的代码：
public static void main(String[] args) { while (true) { new Thread(()-> { }).start(); }}复造代码Tips：卡顿警告~~
其次，线程的创建和销毁是需要时间的，借助线程池能够有效的制止线程频繁的创建和销毁线程，进步程的序响应速度。
问题解答：线程池是什么？为什么要利用线程池？
Executor系统Java中供给了功用完美的Executor系统，用于实现线程池。先来领会下Executor系统中的核心成员间的关系：
Executor系统的最顶层是Executor接口和ExecutorService接口，它们定义了Executor系统的核心功用。
Executor接口Executor接口的正文：
An object that executes submitted Runnable tasks. This interface PRovides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An Executor is normally used instead of explicitly creating threads.
Executor接口十分简单，只定义了execute办法，次要目标是将Runnable使命与施行机造（线程，调度使命等）解耦，供给了施行Runnable使命的办法。
public interface Executor { /** * Executes the given command at some time in the future. The command * may execute in a new thread, in a pooled thread, or in the calling * thread, at the discretion of the {@code Executor} implementation. */ void execute(Runnable command);}复造代码ExecutorService接口ExecutorService接口继承了Executor接口，拓展了Executor接口的才能。ExecutorService接口的正文：
An Executor that provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks.
ExecutorService接口关键办法的声明：
public interface ExecutorService extends Executor { /** * Initiates an orderly shutdown in which previously submitted * tasks are executed, but no new tasks will be accepted. * Invocation has no additional effect if already shut down. */ void shutdown(); /** * Attempts to stop all actively executing tasks, halts the * processing of waiting tasks, and returns a list of the tasks * that were awaiting execution. * This method does not wait for actively executing tasks to * terminate. Use {@link #awaitTermination awaitTermination} to * do that. */ List<Runnable> shutdownNow(); boolean isShutdown(); boolean isTerminated(); /** * Blocks until all tasks have completed execution after a shutdown * request, or the timeout occurs, or the current thread is * interrupted, whichever happens first. */ boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException; <T> Future<T> submit(Callable<T> task); <T> Future<T> submit(Runnable task, T result); /** * Submits a Runnable task for execution and returns a Future * representing that task. The Future's {@code get} method will * return {@code null} upon <em>successful</em> completion. */ Future<?> submit(Runnable task);}复造代码对关键办法做一个申明：
继承自Executor接口：execute：施行Runnable使命；ExecutorService接口定义的办法：submit：施行Runnable或Callable使命，并返回Future；shutdown：允许已提交的使命施行完毕，但不承受新使命的封闭；shutdownNow：测验考试封闭所有使命（正在/期待施行），并返回期待施行的使命。Tips：其余办法建议阅读源码中的正文，即使是提到的4个办法，也要阅读正文。
问题解答：Executor框架是什么？
ThreadPoolExecutor核心流程Executor系统中，各人最熟悉的必然是ThreadPoolExecutor实现了，也是我们可以实现自定义线程池的根底。接下来逐渐阐发ThreadPoolExecutor的实现原理。
构造线程池ThreadPoolExecutor供给了4个构造办法，我们来看参数最全的阿谁构造办法：
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;}复造代码ThreadPoolExecutor的构造办法供给了7个参数：
int corePoolSize：线程池的核心线程数量，创建线程的数量小于等于corePoolSize时，会不断创建线程；int maximumPoolSize：线程池的更大线程数量，当线程数量等于corePoolSize后且队列已满，允许继续创建(maximumPoolSize−corePoolSize)(maximumPoolSize-corePoolSize)(maximumPoolSize−corePoolSize)个线程；long keepAliveTime：线程的更大空闲时间，当创建了超出corePoolSize数量的线程后，那些线程在不施行使命时可以存活的时间，超出keepAliveTime后会被销毁；TimeUnit unit：keepAliveTime的单元；BlockingQueue<Runnable> workQueue：阻塞队列，用于保留期待施行的使命；ThreadFactory threadFactory：线程工场，用于创建线程，默认利用Executors.defaultThreadFactory()。RejectedExecutionHandler handler：回绝战略，当队列已满，且没有空闲的线程时，施行的回绝使命的战略。Tips：有些小伙伴会疑问，若是每次施行一个使命，施行完毕后再施行新使命，线程池照旧会创建corePoolSize个线程吗？谜底是会的，后文解释。
问题解答：创建线程池的参数有哪些？
主控形态CTL与线程池形态ThreadPoolExecutor中定义了主控形态CTL和线程池形态：
/** * The main pool control state, ctl, is an atomic integer packing * two conceptual fields * workerCount, indicating the effective number of threads * runState, indicating whether running, shutting down etc */private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));private static final int COUNT_BITS = Integer.SIZE - 3; // 29private static final int COUNT_MASK = (1 << COUNT_BITS) - 1;// 0001 1111 1111 1111 1111 1111 1111 1111private static final int RUNNING = -1 << COUNT_BITS;// 111 0 0000 0000 0000 0000 0000 0000 0000private static final int SHUTDOWN = 0 << COUNT_BITS;// 000 0 0000 0000 0000 0000 0000 0000 0000private static final int STOP = 1 << COUNT_BITS;// 001 0 0000 0000 0000 0000 0000 0000 0000private static final int TIDYING = 2 << COUNT_BITS;// 010 0 0000 0000 0000 0000 0000 0000 0000private static final int TERMINATED = 3 << COUNT_BITS;// 011 0 0000 0000 0000 0000 0000 0000 0000private static int runStateOf(int c) { return c & ~COUNT_MASK; }private static int workerCountOf(int c) { return c & COUNT_MASK; }private static int ctlOf(int rs, int wc) { return rs | wc; }复造代码CTL包罗了两部门内容：线程池形态（runState，源码中利用rs替代）和工做线程数（workCount，源码中利用wc替代）。当看到位运算符和“MASK”一路呈现时，就应该想到应用了位掩码手艺。
主控形态CTL的默认值是RUNNING | 0即：1110 0000 0000 0000 0000 0000 0000 0000。runStateOf办法返回低29位为0的CTL，与之对应的是线程池形态，workerCountOf办法则返回高3位为0的CTl，用低29位暗示工做线程数量，所以线程池最多允许536870911个线程。
Tips：
工做线程指的是已经创建的线程，其实不必然在施行使命，后文解释；位运算的能够参考编程技巧：“高端”的位运算；Java中二进造利用补码，留意原码，反码和补码间的转换。线程池的形态正文中对线程池的形态做出了详细的申明：
RUNNING: Accept new tasks and process queued tasks
SHUTDOWN: Don't accept new tasks, but process queued tasks
STOP: Don't accept new tasks, don't process queued tasks, and interrupt in-progress tasks
TIDYING: All tasks have terminated, workerCount is zero, the thread transitioning to state TIDYING will run the terminated() hook method
TERMINATED: terminated() has completed
RUNNING：领受新使命，处置队列中的使命；SHUTDOWN：不领受新使命，处置队列中的使命；STOP：不领受新使命，不处置队列中的使命，中断正在施行的使命；TIDYING：所有使命已经施行完毕，而且工做线程为0，转换到TIDYING形态后将施行Hook办法terminated()；TERMINATED：terminated()办法施行完毕。形态的转换正文中也对线程池形态的转换做出了详细申明：
RUNNING -> SHUTDOWN On invocation of shutdown()
(RUNNING or SHUTDOWN) -> STOP On invocation of shutdownNow()
SHUTDOWN -> TIDYING When both queue and pool are empty
STOP -> TIDYING When pool is empty
TIDYING -> TERMINATED When the terminated() hook method has completed
我们通过一张形态转换图来领会线程池形态之间的转换：
连系源码，能够看到线程池的形态从RUNNING到TERMINATED其数值是单调递增的，换句话说线程池从“活着”到“死透”所对应的数值是逐渐增大，所以能够利用数值间的比力去确定线程池处于哪一种形态。
利用线程池我们已经对ThreadPoolExecutor有了一个整体的认知，如今能够创建并利用线程池了：
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(2, 4, 10, TimeUnit.SECONDS, new LinkedBlockingQueue<>(6));threadPoolExecutor.submit(() -> { // 营业逻辑});复造代码那里我利用最“简单”的构造办法，我们看到在线程池中提交使命利用的是submit办法，该办法在笼统类AbstractExecutorService中实现：
public abstract class AbstractExecutorService implements ExecutorService { public Future<?> submit(Runnable task) { if (task == null) throw new NullPointerException(); RunnableFuture<Void> ftask = newTaskFor(task, null); execute(ftask); return ftask; } public Future<?> submit(Runnable task) { if (task == null) throw new NullPointerException(); RunnableFuture<Void> ftask = newTaskFor(task, null); execute(ftask); return ftask; } public <T> Future<T> submit(Callable<T> task) { if (task == null) throw new NullPointerException(); RunnableFuture<T> ftask = newTaskFor(task); execute(ftask); return ftask; }}复造代码submit的重载办法之间只要参数列表的不同，实现逻辑是不异的，均是先封拆RunnableFuture对象，再挪用ThreadPoolExecutor#execute办法。
问题解答：submit()和execute()办法有什么区别？
execute办法继承自Executor接口的execute办法是线程池的关键办法：
public void execute(Runnable command) { // 检测待施行使命 if (command == null) { throw new NullPointerException(); } // 获取主控形态CTL int c = ctl.get(); // STEP 1: 当工做线程数量小于核心线程时，施行addWorker办法 if (workerCountOf(c) < corePoolSize) { if (addWorker(command, true)) { return; } c = ctl.get(); } // 当工做线程数量大于核心线程数量时 // STEP 2: 起首判断线程池能否处于运行形态，接着测验考试添加到队列中 if (isRunning(c) && workQueue.offer(command)) { // 再次查抄线程池形态 int recheck = ctl.get(); // 不再处于RUNNING，则从队列中删除当前使命，并施行回绝战略 if (!isRunning(recheck) && remove(command)) { reject(command); } else if (workerCountOf(recheck) == 0) { addWorker(null, false); } } // STEP 3: 无法添加到队列时，测验考试施行addWorker else if (!addWorker(command, false)) // addWorker施行失败，则施行回绝战略 reject(command);}复造代码阅读execute办法的源码时需要晓得一个前提，addWorker办法会查抄线程池形态和工做线程数量，并施行工做使命。接着来看execute办法的3种施行情况：
STEP 1：线程池形态：RUNNING，工做线程数：小于核心线程数，此时施行addWorker(command, true)；STEP 2：线程池形态：RUNNING，工做线程数：等于核心线程数，队列：未饱和，添加到队列中；STEP 3：线程池形态：RUNNING，工做线程数：等于核心线程数，队列：已饱和，施行addWorker(command, false)。需要重点存眷STEP 1的部门，还记得构造线程池最初的问题吗？STEP 1便解释了为什么一个接一个的施行使命，照旧会创建出corePoolSize个线程。接着我们通过一张流程图展现execute办法的施行流程：
流程丹青得比力“复杂”，因为有些判断看似在一行中施行，现实上是借助了&&运算符短路的特征来决定能否施行，例如isRunning(c) && workQueue.offer(command)中，若是isRunning(c) == false则不会施行workQueue.offer(command)。
addWorker办法private boolean addWorker(Runnable firstTask, boolean core)复造代码返回值为布尔类型暗示能否胜利施行，参数列表中有两个参数：
Runnable firstTask，待施行使命；boolean core，true暗示最多允许创建corePoolSize个线程，false暗示利用最多允许创建maximumPoolSize个线程。在阐发execute办法的过程中，我们提早“剧透”了addWorker办法的功用：
查抄线程池形态和工做线程数量施行工做使命因而addWorker办法的源码部门我们分红两部门来看。
Tips：再次强调本文利用Java 11源码停止阐发，在addWorker办法的实现上Java 11与Java 8存在差别。
查抄线程池形态和工做线程数量第一部门是线程池形态和工做线程数量查抄的源码：
retry:// 获取主控形态CTLfor (int c = ctl.get();;) { // 正文1 // Java 11相对友好良多，削减了良多!的利用，看起来比力契合人的思维 // 那部门判断能够分红两部门： // 1. 至少为SHUTDOWN形态 // 2.前提3选1满足： // 2-1，至少为STOP形态 // 2-2，firstTask不为空 // 2-3，workQueue为空 if (runStateAtLeast(c, SHUTDOWN) && (runStateAtLeast(c, STOP) || firstTask != null || workQueue.isEmpty())) { return false; } for (;;) { // core == true，包管工做线程数量小于核心线程数量 // core == false，包管线程数量小于更大线程数量 if (workerCountOf(c) >= ((core ? corePoolSize : maximumPoolSize) & COUNT_MASK)) { return false; } // 增加工做线程数量并退出 if (compareAndIncrementWorkerCount(c)) { break retry; } // 若是至少是SHUTDOWN形态，则从头施行 c = ctl.get(); if (runStateAtLeast(c, SHUTDOWN)) { continue retry; } }}复造代码正文1的代码其实不复杂，只是需要连系线程池在差别形态下的处置逻辑来阐发：
当形态“至少”为SHUTDOWN时，什么情况不需要处置？添加新的使命（对应前提2-2）队列为空（对应前提2-3）当形态“至少”为STOP时，线程池应当立即停行，不领受，不处置。Tips：线程池形态的部门说线程池形态从RUNNING到TERMINATED是单调递增的，因而在Java 11的实现中才会呈现runStateAtLeast办法。
施行工做使命第二部门是施行工做使命的源码：
boolean workerStarted = false;boolean workerAdded = false;Worker w = null;try { // 创建Worker对象 w = new Worker(firstTask); // 从worker对象中获取线程 final Thread t = w.thread; if (t != null) { // 上锁 final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { int c = ctl.get(); // 线程池形态查抄 // RUNNING形态，或者“小于”STOP形态（处置队列中的使命） if (isRunning(c) || (runStateLessThan(c, STOP) && firstTask == null)) { // 线程形态查抄 if (t.getState() != Thread.State.NEW) { throw new IllegalThreadStateException(); } // 将Worker对象添加到workers中 workers.add(w); workerAdded = true; int s = workers.size(); if (s > largestPoolSize) { // 记录线程池中呈现过的更大线程数 largestPoolSize = s; } } } finally { mainLock.unlock(); } if (workerAdded) { // 启动线程 t.start(); workerStarted = true; } }} finally { if (! workerStarted) { // addWorker施行失败 // addWorkerFailed中包罗工做线程数减1的逻辑 addWorkerFailed(w); } }return workerStarted;复造代码连系两部门代码，一个正向流程是如许的：
查抄形态：查抄能否允许创建Worker，若是允许施行compareAndIncrementWorkerCount(c)，CTL中工做线程数量+1；施行使命：创建Worker对象，通过Worker对象获取线程，添加到workers中，最初启动线程。回过甚看我们之前不断提到的工做线程，现实上是Worker对象，我们能够近似的将Worker对象和工做线程画上等号。
问题解答：线程池中的线程是什么时间创建的?
三调addWorkerexecute办法中，有3种情况挪用addWorker办法：
STEP 1：addWorker(command, true)STEP 2：addWorker(null, false)STEP 3：addWorker(command, false)STEP 1和STEP 3很好理解，STEP 1最多允许创建corePoolSize个线程，STEP 3最多允许创建maximumPoolSize个线程。STEP 2就比力难理解了，传入了空使命然后挪用addWorker办法。
什么情况下会施行到addWorker(null, false)？
第1个前提：workerCount≥corePoolSizeworkerCount \geq corePoolSizeworkerCount≥corePoolSize。第2个前提：isRunning(c) && workQueue.offer(command)第3个前提：workerCountOf(recheck) == 0处于RUNNING形态的前提不难理解，矛盾的是第1个前提和第3个前提。按照那两个前提能够得到：corePoolSize≤workCount=0corePoolSize \leq workCount = 0corePoolSize≤workCount=0，也就是说允许创建核心线程数为0的线程池。
接着我们来看addWorker(null, false)做了什么？创建了Worker对象，添加到workers中，并挪用了一次Thread.start，固然没有任何待施行的使命。
为什么要创建一个Worker对象？别忘了，**已经施行过workQueue.offer(command)了，需要包管线程池中至少有一个Worker，才气施行workQueue**中的使命。
“东西人”Worker现实上ThreadPoolExecutor维护的工做线程就是Worker对象，我们来看Worker类的原码：
private final class Worker extends AbstractQueuedSynchronizer implements Runnable { final Thread thread; Runnable firstTask; volatile long completedTasks; Worker(Runnable firstTask) { setState(-1); this.firstTask = firstTask; // 通过默认线程工场创建线程 this.thread = getThreadFactory().newThread(this); } public void run() { runWorker(this); }}复造代码Worker继承自AbstractQueuedSynchronizer，并实现了Runnable接口。
我们重点存眷构造办法，尤其是this.thread = getThreadFactory().newThread(this)，通过线程工场创建线程，传入的Runnable接口是谁？
是Worker对象自己，也就是说若是有worker.getThread().start()，此时会施行Worker.run办法。
Tips：
AbstractQueuedSynchronizer就是大名鼎鼎的AQS，Worker借助AQS实现非重入独占锁，不外那部门不是今天的重点；Woker对象与本身的成员变量thread的关系可谓是水乳交融，好好梳理下，不然会很紊乱。runWorker办法runWorker办法传入的是Worker对象自己，来看办法实现：
final void runWorker(Worker w) { // 正文1 Thread wt = Thread.currentThread(); // Worker对象中获取施行使命 Runnable task = w.firstTask; // 将Worker对象中的使命置空 w.firstTask = null; w.unlock(); boolean completedAbruptly = true; try { // 正文2 while (task != null || (task = getTask()) != null) { w.lock(); // 线程池的部门形态要中断正在施行的使命 if ((runStateAtLeast(ctl.get(), STOP) || (Thread.interrupted() && runStateAtLeast(ctl.get(), STOP))) && !wt.isInterrupted()) { wt.interrupt(); } try { beforeExecute(wt, task); try { // 施行使命 task.run(); afterExecute(task, null); } catch (Throwable ex) { afterExecute(task, ex); throw ex; } } finally { task = null; w.completedTasks++; w.unlock(); } } completedAbruptly = false; } finally { processWorkerExit(w, completedAbruptly); }}复造代码各人可能会对正文1的部门比力利诱，那个Thread wt = Thread.currentThread()是什么鬼？别急，我带你从头梳理一下。
以利用线程池中的代码为例，假设是初次施行，我们看主线程做了什么：
适才也说了，Worker对象的线程在启动后施行worker.run，也便是在runWorker办法中Thread.currentThread()是Worker对象的线程，并不是主线程。
再来看正文2的部门，第一次进入轮回时，施行的task是Runnable task = w.firstTask，即初度判断task != null，第二次进入轮回时，task是通过task = getTask()获取的。
线程池中，除了当前Worker正在施行的使命，还有谁能够供给待施行使命？谜底是队列，因而我们能够合理得推测getTask()是获取队列中的使命。
getTask办法private Runnable getTask() { // 前次从队列中获取使命能否超时 boolean timedOut = false; for (;;) { // 线程池形态判断，某些形态下不需要处置队列中的使命 int c = ctl.get(); if (runStateAtLeast(c, SHUTDOWN) && (runStateAtLeast(c, STOP) || workQueue.isEmpty())) { decrementWorkerCount(); return null; } int wc = workerCountOf(c); // allowCoreThreadTimeOut能否允许核心线程超时销毁，默认为false // 通过allowCoreThreadTimeOut办法设置 // wc > corePoolSize为true暗示启用了非核心线程 boolean timed = allowCoreThreadTimeOut || wc > corePoolSize; // wc > maximumPoolSize，可能的情况是因为同时施行了setMaximumPoolSize办法 // timed && timedOut为true时，暗示前次获取使命超时，当前需要停止超时控造 // wc > 1 || workQueue.isEmpty()，工做线程数量大于1或队列为空 if ((wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty())) { // 削减工做线程数量 if (compareAndDecrementWorkerCount(c)) { return null; } continue; } try { // 正文1 // 从队列中获取待施行使命 Runnable r = timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take(); if (r != null) { return r; } timedOut = true; } catch (InterruptedException retry) { timedOut = false; } }}复造代码正文1的部门有两种获取使命的体例：
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)，获取队首元素，若是当前队列为空，则期待指按时间后返回null；workQueue.take()，获取队首元素，若是队列为空，则不断期待，曲到有返回值。线程池只会在一种情况下利用workQueue.take，即不允许核心线程超时销毁，同时线程池的工做线程数量小于核心线程数量，连系runWorker办法的源码我们能够得知，此时借助了阻塞队列的才能，包管runsWoker办法不断停留在task = getTask()上，曲到getTask()返回响应的使命。
而在选择利用workQueue.poll时存在两种情况：
允许核心线程超时销毁，即allowCoreThreadTimeOut == true；当前工做线程数大于核心线程数，即线程池已经创建足够数量的核心线程，而且队列已经饱和，起头创建非核心线程处置使命。连系runWorker办法的源码我们能够晓得，若是队列中的使命已经被消耗完毕，即getTask()返回null，则会跳出while轮回，施行processWorkerExit办法。
processWorkerExit办法private void processWorkerExit(Worker w, boolean completedAbruptly) { // runWorker施行失败的场景 if (completedAbruptly) { decrementWorkerCount(); } final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { completedTaskCount += w.completedTasks; // 从workers中删除Worker workers.remove(w); } finally { mainLock.unlock(); } // 按照线程池形态判断能否完毕线程池 tryTerminate(); int c = ctl.get(); // STOP之下的形态，runWorker一般完毕时completedAbruptly == false // 包管至少有1个worker，用于处置队列中的使命 if (runStateLessThan(c, STOP)) { if (!completedAbruptly) { int min = allowCoreThreadTimeOut ? 0 : corePoolSize; if (min == 0 && ! workQueue.isEmpty()) { min = 1; } if (workerCountOf(c) >= min){ return; } } // runWorker异常退出时，即completedAbruptly == true // 或者是workers存活少于1个 addWorker(null, false); }}复造代码processWorkerExit办法做了3件事：
移除“多余”的Worker对象（允许销毁的核心线程或者非核心线程）；测验考试修改线程池形态；包管在至少存活1个Worker对象。Tips：我跳过了tryTerminate()办法的阐发，对，是成心的~~
问题解答：线程池的底层原理是若何实现的？
销毁非核心线程设想一个场景：已经创建了足够数量的核心线程，而且队列已经饱和，仍然有使命提交时，会是如何的施行流程？
线程池创建非核心线程处置使命，当非核心线程施行完毕后其实不会立即销毁，而是和核心线程一路去向理队列中的使命。那么当所有的使命都处置完毕之后呢？
回到runWorker中，当所有使命施行完毕后再次进入轮回，getTask中判断工做线程数大于和核心线程数，此时启用workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)，而keepAliveTime就是构建线程池时设定的线程更大空闲时间，当超越keepAliveTime后仍旧没有获得使命返回null，跳出runWorker的轮回，施行processWorkerExit销毁非核心线程。
ThreadPoolExecutor拾遗目前我们已经详细阐发了线程池的施行流程，那里我会弥补一些前文未涉及到的内容，因为是弥补内容，所以涉及不会详细的解释源码。
预创建线程我们在提到线程池的长处时会出格强调一句，池内保留了创建好的资本，利用时间接取出，但线程池仿佛照旧是初次接到使命后才会创建资本啊？
现实上，线程池供给prestartCoreThread办法，用于预创建核心线程：
public boolean prestartCoreThread() { return workerCountOf(ctl.get()) < corePoolSize && addWorker(null, true);}复造代码若是你的法式需要做出极致的优化，能够选择预创建核心线程。
封闭和立即封闭ThreadPoolExecutor供给了两个封闭的功用shutdown和shutdownNow：
public void shutdown() { final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { checkShutdownAccess(); advanceRunState(SHUTDOWN); // 中断空闲线程 interruptIdleWorkers(); // ScheduledThreadPoolExecutor的hook onShutdown(); } finally { mainLock.unlock(); } tryTerminate();}public List<Runnable> shutdownNow() { List<Runnable> tasks; final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { checkShutdownAccess(); advanceRunState(STOP); // 中断所有线程 interruptWorkers(); tasks = drainQueue(); } finally { mainLock.unlock(); } tryTerminate(); return tasks;}复造代码两者的不同仍是很明显的：
shutdown将线程池的形态改为SHUTDOWN，而shutdownNow则改为STOP；shutdown不返回队列中的使命，而shutdownNow返回队列中的使命，因为STOP形态不会再去施行队列的使命；shutdown中断空闲线程，而shutdownNow则是中断所有线程。从实现效果上来看封闭shutdown会更“暖和”一些，而立即封闭shutdownNow则更为“强烈”，似乎语气中带着无可置疑。
回绝战略线程池不会无前提的领受使命，有两种情况下它会回绝使命：
核心线程已满，添加到队列后，线程池不再处于RUNNING形态，此时从队列删除使命，并施行回绝战略；核心线程已满，队列已满，非核心线程已满，此时施行回绝战略。Java供给了RejectedExecutionHandler接口：
public interface RejectedExecutionHandler { void rejectedExecution(Runnable r, ThreadPoolExecutor executor);}复造代码因而，我们能够通过实现RejectedExecutionHandler接口，完成自定义回绝战略。别的，Java中也供给了4种默认回绝战略：
AbortPolicy：间接抛出异常；CallerRunsPolicy：提交使命的线程施行；DiscardOldestPolicy：丢弃队列中更先参加的线程；DiscardPolicy：间接丢弃，就是啥也不干。源码十分简单，各人自行阅读即可。
Java供给了哪些线程池若是不想本身定义线程池，Java也贴心的供给了4种内置线程池，默认线程池通过Executors获取。
Java的定名中，s后缀凡是是对应东西类，凡是供给大量静态办法，例如：Collections之于Collection。所以即使属于Executor系统中的一员，但却没法子在“族谱”上呈现，打工人的悲凉命运。
FixedThreadPoolpublic 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);}复造代码固定大小线程池，核心线程数和更大线程数一样，看起来都还不错，次要的问题是通过无参构造器创建的LinkedBlockingQueue，它允许的更大长度是Integer.MAX_VALUE。
**Tips：**那也就是为什么《阿里巴巴Java开发手册》中不保举的原因。
CachedThreadPoolpublic 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);}复造代码能够说是“无限大”的线程池，接到使命就创建新线程，别的**SynchronousQueue长短常特殊的队列，不存储数据，每个put操做对应一个take操做**。我们来阐发下现实可能发作的情况：
前提：大量并发涌入提交第一个使命，进入队列，判断核心线程数为0，施行addWorker(null, false)，对应execute的SETP 2；提交第二个使命，假设第一个使命未完毕，第二个使命间接提交到队列中；提交第三个使命，假设第一个使命未完毕，无法添加到队列中，施行addWorker(command, false)对应execute的SETP 3。也就是说，只要提交的够快，就会无限创建线程。
SingleThreadExecutorpublic 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));}复造代码只要一个线程的线程池，问题也是在于LinkedBlockingQueue，能够“无限”的领受使命。
ScheduledExecutorpublic static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) { return new ScheduledThreadPoolExecutor(corePoolSize);}public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize, ThreadFactory threadFactory) { return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);}public static ScheduledExecutorService newSingleThreadScheduledExecutor() { return new DelegatedScheduledExecutorService(new ScheduledThreadPoolExecutor(1));}public static ScheduledExecutorService newSingleThreadScheduledExecutor(ThreadFactory threadFactory) { return new DelegatedScheduledExecutorService(new ScheduledThreadPoolExecutor(1, threadFactory));}复造代码用来施行按时使命，DelegatedScheduledExecutorService是对ScheduledExecutorService的包拆。
在Executor系统的“族谱”中，是有表现到ScheduledExecutorService和ScheduledThreadPoolExecutor的，那部门留给各人自行阐发了。
除了以上4种内置线程池外，Java还供给了内置的ForkJoinPool：
public static ExecutorService newWorkStealingPool(int parallelism) { return new ForkJoinPool(parallelism, ForkJoinPool.defaultForkJoinWorkerThreadFactory, null, true);}public static ExecutorService newWorkStealingPool() { return new ForkJoinPool(Runtime.getRuntime().availableProcessors(), ForkJoinPool.defaultForkJoinWorkerThreadFactory, null, true);}复造代码那部门是Java 8之后供给的，我们暂时按下不表，放到后期关于Fork/Join框架中详细解释。
问题解答：Java供给了哪些线程池？
合理设置线程池凡是我们在议论合理设置线程池的时候，指的是设置线程池的corePoolSize和maximumPoolSize，合理的设置可以更大化的阐扬线程池的才能。
我们先来看美团手艺团队的调研成果：
无论是哪种公式，都是基于理论得出的成果，但往往理论到工程还有很长得一段路要走。
根据我的经历，合理的设置线程池能够汇总成一句话：按照理论公式预估初始设置，随后对核心营业停止压测调整线程池设置。
Java也供给了动态调整线程池的才能：
public void setThreadFactory(ThreadFactory threadFactory);public void setRejectedExecutionHandler(RejectedExecutionHandler handler);public void setCorePoolSize(int corePoolSize);public void setMaximumPoolSize(int maximumPoolSize);public void setKeepAliveTime(long time, TimeUnit unit);复造代码除了workQueue都能调整，本文不讨论线程池动态调整的实现。
Tips：
调研成果源自于《Java线程池实现原理及其在美团营业中的理论》；该篇文章中也详细的讨论了动态化线程池的思绪，保举阅读。结语线程池的大部门内容就到那里完毕了，希望各人够通过本篇文章解答绝大部门关于线程池的问题，带给各人一些帮忙，若是有错误或者差别的设法，欢送各人留言讨论
发表评论