java多线程 线程池与ThreadPoolExecutor
目录
线程池相关的区别
实现 Runnable 接口和 Callable 接口的区别
执行 execute()方法和 submit()方法的区别
shutdown()VSshutdownNow()
isTerminated() VS isShutdown()
ThreadPoolExecutor详解
ThreadPoolExecutor构造函数与参数
corePoolSize理解
KeepAliveTime理解
workQueue理解
ThreadPoolExecutor 饱和策略定义
ctl理解
线程池有几种状态吗？
线程池的状态是如何变迁的吗
示例代码:Runnable+ThreadPoolExecutor
Callable+ThreadPoolExecutor示例代码
线程池处理任务的流程
向线程池提交任务
关闭线程池
线程池submit与异常
线程池高级理论
为什么要把任务先放在任务队列里面，而不是把线程先拉满到最大线程数？
如何修改原生线程池，使得可以先拉满线程数再入任务队列排队？
Tomcat 中的定制化线程池实现
如果线程池中的线程在执行任务的时候，抛异常了，会怎么样？
原生线程池的核心线程一定伴随着任务慢慢创建的吗？
线程池的核心线程在空闲的时候一定不会被回收吗？
线程池如何动态修改核心线程数和最大线程数？
动态修改参数的实现
如果要让你设计一个线程池，你要怎么设计？
线程池最佳实践
线程池在实际项目的使用场景
创建线程池的方法与Executors的弊端
合理地配置线程池
上下文切换
常规配置
分拆任务与队列选择
美团的骚操作
线程池的监控
建议不同类别的业务用不同的线程池
别忘记给线程池命名
线程池自定义异常处理方法
本文参考 java并发编程的艺术
记一次线程池引发的故障 排查下来是三歪的锅
两道面试题，深入线程池，连环17问
docs/java/concurrent/java-thread-pool-summary.md · SnailClimb/JavaGuide - Gitee.com
docs/java/concurrent/java-thread-pool-best-practices.md · SnailClimb/JavaGuide - Gitee.com
池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、Http 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。
线程池提供了一种限制和管理资源（包括执行一个任务）。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。
这里借用《Java 并发编程的艺术》提到的来说一下使用线程池的好处：
降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
线程池相关的区别
实现 Runnable 接口和 Callable 接口的区别
Runnable自 Java 1.0 以来一直存在，但Callable仅在 Java 1.5 中引入,目的就是为了来处理Runnable不支持的用例。Runnable 接口 不会返回结果或抛出检查异常，但是 Callable 接口 可以。所以，如果任务不需要返回结果或抛出异常推荐使用 Runnable 接口 ，这样代码看起来会更加简洁。
工具类 Executors 可以实现将 Runnable 对象转换成 Callable 对象。（Executors.callable(Runnable task) 或 Executors.callable(Runnable task, Object result)）。
Runnable.java
@FunctionalInterface
public interface Runnable {
/**
* 被线程执行，没有返回值也无法抛出异常
*/
public abstract void run();
}
Callable.java
@FunctionalInterface
public interface Callable {
/**
* 计算结果，或在无法这样做时抛出异常。
* @return 计算得出的结果
* @throws 如果无法计算结果，则抛出异常
*/
V call() throws Exception;
}
执行 execute()方法和 submit()方法的区别
execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；
submit()方法用于提交需要返回值的任务。线程池会返回一个 Future 类型的对象，通过这个 Future 对象可以判断任务是否执行成功，并且可以通过 Future 的 get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 get(long timeout，TimeUnit unit)方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。
我们以 AbstractExecutorService 接口 中的一个 submit 方法为例子来看看源代码：
public Future submit(Runnable task) {
if (task == null) throw new NullPointerException();
RunnableFuture ftask = newTaskFor(task, null);
execute(ftask);
return ftask;
}
上面方法调用的 newTaskFor 方法返回了一个 FutureTask 对象。
protected RunnableFuture newTaskFor(Runnable runnable, T value) {
return new FutureTask(runnable, value);
}
我们再来看看execute()方法：
public void execute(Runnable command) {
...
}
shutdown()VSshutdownNow()
shutdown（） :关闭线程池，线程池的状态变为 SHUTDOWN。线程池不再接受新任务了，但是队列里的任务得执行完毕。
shutdownNow（） :关闭线程池，线程的状态变为 STOP。线程池会终止当前正在运行的任务，并停止处理排队的任务并返回正在等待执行的 List。
isTerminated() VS isShutdown()
isShutDown 当调用 shutdown() 方法后返回为 true。
isTerminated 当调用 shutdown() 方法后，并且所有提交的任务完成后返回为 true
ThreadPoolExecutor详解
ThreadPoolExecutor构造函数与参数
ThreadPoolExecutor 类中提供的四个构造方法。我们来看最长的那个，其余三个都是在这个构造方法的基础上产生（其他几个构造方法说白点都是给定某些默认参数的构造方法比如默认制定拒绝策略是什么）。
/**
* 用给定的初始参数创建一个新的ThreadPoolExecutor。
*/
public ThreadPoolExecutor(int corePoolSize,//线程池的核心线程数量
int maximumPoolSize,//线程池的最大线程数
long keepAliveTime,//当线程数大于核心线程数时，多余的空闲线程存活的最长时间
TimeUnit unit,//时间单位
BlockingQueue 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 3 个最重要的参数：
1 corePoolSize : 核心线程数线程数定义了最小可以同时运行的线程数量。
2 maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
3 workQueue: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
ThreadPoolExecutor其他常见参数 :
1 keepAliveTime:当线程池中的线程数量大于 corePoolSize 的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 keepAliveTime才会被回收销毁；
2 unit : keepAliveTime 参数的时间单位。
3 threadFactory :executor 创建新线程的时候会用到。
4 handler :饱和策略。关于饱和策略下面单独介绍一下。
下面这张图可以加深你对线程池中各个参数的相互关系的理解（图片来源：《Java 性能调优实战》）：
corePoolSize理解
此时线程数小于核心线程数，并且线程都处于空闲状态，现提交一个任务，是新起一个线程还是给之前创建的线程？
李老是这样说的：If fewer than corePoolSize threads are running, try to start a new thread with the given command as its first task.
我觉得把 threads are running 去了，更合理一些，此时线程池会新起一个线程来执行这个新任务，不管老线程是否空闲。
你是如何理解核心线程的 ?
从上一个问题可以看出，线程池虽说默认是懒创建线程，但是它实际是想要快速拥有核心线程数的线程。核心线程指的是线程池承载日常任务的中坚力量，也就是说本质上线程池是需要这么些数量的线程来处理任务的，所以在懒中又急着创建它。
而最大线程数其实是为了应付突发状况。
举个装修的例子，正常情况下施工队只要 5 个人去干活，这 5 人其实就是核心线程，但是由于工头接的活太多了，导致 5 个人在约定工期内干不完，所以工头又去找了 2 个人来一起干，所以 5 是核心线程数，7 是最大线程数。
平时就是 5 个人干活，特别忙的时候就找 7 个，等闲下来就会把多余的 2 个辞了。
看到这里你可能会觉得核心线程在线程池里面会有特殊标记？
并没有，不论是核心还是非核心线程，在线程池里面都是一视同仁，当淘汰的时候不会管是哪些线程，反正留下核心线程数个线程即可，下文会作详解。
KeepAliveTime理解
这就是上面提到的，线程池其实想要的只是核心线程数个线程，但是又预留了一些数量来预防突发状况，当突发状况过去之后，线程池希望只维持核心线程数的线程，所以就弄了个 KeepAliveTime，当线程数大于核心数之后，如果线程空闲了一段时间（KeepAliveTime），就回收线程，直到数量与核心数持平。
workQueue理解
缓存任务供线程获取，这里要注意限制工作队列的大小。队列长了，堆积的任务就多，堆积的任务多，后面任务等待的时长就长。
想想你点击一个按钮是一直转圈等半天没反应舒服，还是直接报错舒服，所以有时心是好的，想尽量完成提交的任务，但是用户体验不如直接拒绝。更有可能由于允许囤积的任务过多，导致资源耗尽而系统崩溃。
所以工作队列起到一个缓冲作用，具体队列长度需要结合线程数，任务的执行时长，能承受的等待时间等。
ThreadPoolExecutor 饱和策略定义
如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，ThreadPoolTaskExecutor 定义一些策略:
1 ThreadPoolExecutor.AbortPolicy ：抛出 RejectedExecutionException来拒绝新任务的处理。
2 ThreadPoolExecutor.CallerRunsPolicy ：调用执行自己的线程运行任务，也就是直接在调用execute方法的线程中运行(run)被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。
3 ThreadPoolExecutor.DiscardPolicy ：不处理新任务，直接丢弃掉。
4 ThreadPoolExecutor.DiscardOldestPolicy ： 此策略将丢弃最早的未处理的任务请求。
也可以自定义拒绝策略，实现 RejectedExecutionHandler 这个接口即可。
举个例子：
Spring 通过 ThreadPoolTaskExecutor 或者我们直接通过 ThreadPoolExecutor 的构造函数创建线程池的时候，当我们不指定 RejectedExecutionHandler 饱和策略的话来配置线程池的时候默认使用的是 ThreadPoolExecutor.AbortPolicy。在默认情况下，ThreadPoolExecutor 将抛出 RejectedExecutionException 来拒绝新来的任务 ，这代表你将丢失对这个任务的处理。 对于可伸缩的应用程序，建议使用 ThreadPoolExecutor.CallerRunsPolicy。当最大池被填满时，此策略为我们提供可伸缩队列。（这个直接查看 ThreadPoolExecutor 的构造函数源码就可以看出，比较简单的原因，这里就不贴代码了。）
ctl理解
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
其实看下注释就很清楚了，ctl 是一个涵盖了两个概念的原子整数类，它将工作线程数和线程池状态结合在一起维护，低 29 位存放 workerCount，高 3 位存放 runState。
其实并发包中有很多实现都是一个字段存多个值的，比如读写锁的高 16 位存放读锁，低 16 位存放写锁，这种一个字段存放多个值可以更容易的维护多个值之间的一致性，也算是极简主义。
线程池有几种状态吗？
RUNNING：能接受新任务，并处理阻塞队列中的任务
SHUTDOWN：不接受新任务，但是可以处理阻塞队列中的任务
STOP：不接受新任务，并且不处理阻塞队列中的任务，并且还打断正在运行任务的线程，就是直接撂担子不干了！
TIDYING：所有任务都终止，并且工作线程也为0，处于关闭之前的状态，运行terminated()钩子方法
TERMINATED：已关闭。terminated()已经完成
线程池的状态是如何变迁的吗
示例代码:Runnable+ThreadPoolExecutor
首先创建一个 Runnable 接口的实现类（当然也可以是 Callable 接口，我们上面也说了两者的区别。）
MyRunnable.java
import java.util.Date;
/**
* 这是一个简单的Runnable类，需要大约5秒钟来执行其任务。
* @author shuang.kou
*/
public class MyRunnable implements Runnable {
private String command;
public MyRunnable(String s) {
this.command = s;
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date());
processCommand();
System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date());
}
private void processCommand() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public String toString() {
return this.command;
}
}
编写测试程序，我们这里以阿里巴巴推荐的使用 ThreadPoolExecutor 构造函数自定义参数的方式来创建线程池。
ThreadPoolExecutorDemo.java
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class ThreadPoolExecutorDemo {
private static final int CORE_POOL_SIZE = 5;
private static final int MAX_POOL_SIZE = 10;
private static final int QUEUE_CAPACITY = 100;
private static final Long KEEP_ALIVE_TIME = 1L;
public static void main(String[] args) {
//使用阿里巴巴推荐的创建线程池的方式
//通过ThreadPoolExecutor构造函数自定义参数创建
ThreadPoolExecutor executor = new ThreadPoolExecutor(
CORE_POOL_SIZE,
MAX_POOL_SIZE,
KEEP_ALIVE_TIME,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(QUEUE_CAPACITY),
new ThreadPoolExecutor.CallerRunsPolicy());
for (int i = 0; i < 10; i++) {
//创建WorkerThread对象（WorkerThread类实现了Runnable 接口）
Runnable worker = new MyRunnable("" + i);
//执行Runnable
executor.execute(worker);
}
//终止线程池
executor.shutdown();
while (!executor.isTerminated()) {
}
System.out.println("Finished all threads");
}
}
可以看到我们上面的代码指定了：
corePoolSize: 核心线程数为 5。
maximumPoolSize ：最大线程数 10
keepAliveTime : 等待时间为 1L。
unit: 等待时间的单位为 TimeUnit.SECONDS。
workQueue：任务队列为 ArrayBlockingQueue，并且容量为 100;
handler:饱和策略为 CallerRunsPolicy。
Output：
pool-1-thread-3 Start. Time = Sun Apr 12 11:14:37 CST 2020
pool-1-thread-5 Start. Time = Sun Apr 12 11:14:37 CST 2020
pool-1-thread-2 Start. Time = Sun Apr 12 11:14:37 CST 2020
pool-1-thread-1 Start. Time = Sun Apr 12 11:14:37 CST 2020
pool-1-thread-4 Start. Time = Sun Apr 12 11:14:37 CST 2020
pool-1-thread-3 End. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-4 End. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-1 End. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-5 End. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-1 Start. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-2 End. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-5 Start. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-4 Start. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-3 Start. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-2 Start. Time = Sun Apr 12 11:14:42 CST 2020
pool-1-thread-1 End. Time = Sun Apr 12 11:14:47 CST 2020
pool-1-thread-4 End. Time = Sun Apr 12 11:14:47 CST 2020
pool-1-thread-5 End. Time = Sun Apr 12 11:14:47 CST 2020
pool-1-thread-3 End. Time = Sun Apr 12 11:14:47 CST 2020
pool-1-thread-2 End. Time = Sun Apr 12 11:14:47 CST 2020
Callable+ThreadPoolExecutor示例代码
MyCallable.java
import java.util.concurrent.Callable;
public class MyCallable implements Callable {
@Override
public String call() throws Exception {
Thread.sleep(1000);
//返回执行当前 Callable 的线程名字
return Thread.currentThread().getName();
}
}
CallableDemo.java
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class CallableDemo {
private static final int CORE_POOL_SIZE = 5;
private static final int MAX_POOL_SIZE = 10;
private static final int QUEUE_CAPACITY = 100;
private static final Long KEEP_ALIVE_TIME = 1L;
public static void main(String[] args) {
//使用阿里巴巴推荐的创建线程池的方式
//通过ThreadPoolExecutor构造函数自定义参数创建
ThreadPoolExecutor executor = new ThreadPoolExecutor(
CORE_POOL_SIZE,
MAX_POOL_SIZE,
KEEP_ALIVE_TIME,
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(QUEUE_CAPACITY),
new ThreadPoolExecutor.CallerRunsPolicy());
List> futureList = new ArrayList<>();
Callable callable = new MyCallable();
for (int i = 0; i < 10; i++) {
//提交任务到线程池
Future future = executor.submit(callable);
//将返回值 future 添加到 list，我们可以通过 future 获得 执行 Callable 得到的返回值
futureList.add(future);
}
for (Future fut : futureList) {
try {
System.out.println(new Date() + "::" + fut.get());
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace();
}
}
//关闭线程池
executor.shutdown();
}
}
Output:
Wed Nov 13 13:40:41 CST 2019::pool-1-thread-1
Wed Nov 13 13:40:42 CST 2019::pool-1-thread-2
Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3
Wed Nov 13 13:40:42 CST 2019::pool-1-thread-4
Wed Nov 13 13:40:42 CST 2019::pool-1-thread-5
Wed Nov 13 13:40:42 CST 2019::pool-1-thread-3
Wed Nov 13 13:40:43 CST 2019::pool-1-thread-2
Wed Nov 13 13:40:43 CST 2019::pool-1-thread-1
Wed Nov 13 13:40:43 CST 2019::pool-1-thread-4
Wed Nov 13 13:40:43 CST 2019::pool-1-thread-5
线程池处理任务的流程
当向线程池提交一个任务之后，线程池是如何处理这个任务的呢？
中我们使用 executor.execute(worker)来提交一个任务到线程池中去，这个方法非常重要，下面我们来看看它的源码：
// 存放线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static int workerCountOf(int c) {
return c & CAPACITY;
}
//任务队列
private final BlockingQueue workQueue;
public void execute(Runnable command) {
// 如果任务为null，则抛出异常。
if (command == null)
throw new NullPointerException();
// ctl 中保存的线程池当前的一些状态信息
int c = ctl.get();
// 下面会涉及到 3 步 操作
// 1.首先判断当前线程池中之行的任务数量是否小于 corePoolSize
// 如果小于的话，通过addWorker(command, true)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
// 2.如果当前之行的任务数量大于等于 corePoolSize 的时候就会走到这里
// 通过 isRunning 方法判断线程池状态，线程池处于 RUNNING 状态才会被并且队列可以加入任务，该任务才会被加入进去
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);
}
//3. 通过addWorker(command, false)新建一个线程，并将任务(command)添加到该线程中；然后，启动该线程从而执行任务。
//如果addWorker(command, false)执行失败，则通过reject()执行相应的拒绝策略的内容。
else if (!addWorker(command, false))
reject(command);
}
处理流程图如图
从图中可以看出，当提交一个新任务到线程池时，线程池的处理流程如下。
1)线程池判断核心线程池里的线程是否都在执行任务。如果不是，则创建一个新的工作 线程来执行任务。如果核心线程池里的线程都在执行任务，则进入下个流程。
2)线程池判断工作队列是否已经满。如果工作队列没有满，则将新提交的任务存储在这 个工作队列里。如果工作队列满了，则进入下个流程。
3)线程池判断线程池的线程是否都处于工作状态。如果没有，则创建一个新的工作线程 来执行任务。如果已经满了，则交给饱和策略来处理这个任务。
addWorker 这个方法主要用来创建新的工作线程，如果返回 true 说明创建和启动工作线程成功，否则的话返回的就是 false。
// 全局锁，并发操作必备
private final ReentrantLock mainLock = new ReentrantLock();
// 跟踪线程池的最大大小，只有在持有全局锁mainLock的前提下才能访问此集合
private int largestPoolSize;
// 工作线程集合，存放线程池中所有的（活跃的）工作线程，只有在持有全局锁mainLock的前提下才能访问此集合
private final HashSet workers = new HashSet<>();
//获取线程池状态
private static int runStateOf(int c) { return c & ~CAPACITY; }
//判断线程池的状态是否为 Running
private static boolean isRunning(int c) {
return c < SHUTDOWN;
}
/**
* 添加新的工作线程到线程池
* @param firstTask 要执行
* @param core参数为true的话表示使用线程池的基本大小，为false使用线程池最大大小
* @return 添加成功就返回true否则返回false
*/
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (;;) {
//这两句用来获取线程池的状态
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs >= SHUTDOWN &&
! (rs == SHUTDOWN &&
firstTask == null &&
! workQueue.isEmpty()))
return false;
for (;;) {
//获取线程池中线程的数量
int wc = workerCountOf(c);
// core参数为true的话表明队列也满了，线程池大小变为 maximumPoolSize
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false;
//原子操作将workcount的数量加1
if (compareAndIncrementWorkerCount(c))
break retry;
// 如果线程的状态改变了就再次执行上述操作
c = ctl.get();
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
}
// 标记工作线程是否启动成功
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 {
//获取线程池状态
int rs = runStateOf(ctl.get());
//rs < SHUTDOWN 如果线程池状态依然为RUNNING,并且线程的状态是存活的话，就会将工作线程添加到工作线程集合中
//(rs=SHUTDOWN && firstTask == null)如果线程池状态小于STOP，也就是RUNNING或者SHUTDOWN状态下，同时传入的任务实例firstTask为null，则需要添加到工作线程集合和启动新的Worker
// firstTask == null证明只新建线程而不执行任务
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && firstTask == null)) {
if (t.isAlive()) // precheck that t is startable
throw new IllegalThreadStateException();
workers.add(w);
//更新当前工作线程的最大容量
int s = workers.size();
if (s > largestPoolSize)
largestPoolSize = s;
// 工作线程是否启动成功
workerAdded = true;
}
} finally {
// 释放锁
mainLock.unlock();
}
如果成功添加工作线程，则调用Worker内部的线程实例t的Thread#start()方法启动真实的线程实例
if (workerAdded) {
t.start();
/// 标记线程启动成功
workerStarted = true;
}
}
} finally {
// 线程启动失败，需要从工作线程中移除对应的Worker
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
} 更多关于线程池源码分析的内容推荐这篇文章：硬核干货：4W字从源码上分析JUC线程池ThreadPoolExecutor的实现原理
ThreadPoolExecutor执行execute()方法的示意图如图
ThreadPoolExecutor执行execute方法分下面4种情况。
1)如果当前运行的线程少于corePoolSize, 则创建新线程来执行任务（注意，执行这一步骤 需要获取全局锁）。
2)如果运行的线程等于或多于corePoolSize, 则将任务加入BlockingQueue。
3)如果无法将任务加入BlockingQueue (队列已满），则创建新的线程来处理任务（注意，执行这一步骤需要获取全局锁）。
4)如果创建新线程将使当前运行的线程超出maximumPoolSize, 任务将被拒绝，并调用 RejectedExecutionHandler.rejectedExecuti on()方法。
ThreadPoolExecutor采取上述步骤的总体设计思路，是为了在执行execute()方法时，尽可能 地避免获取全局锁（那将会是一个严重的可伸缩瓶颈）。在ThreadPoolExecutor完成预热之后 （当前运行的线程数大于等于corePoolSize), 几乎所有的execute()方法调用都是执行步骤2, 而 步骤2不需要获取全局锁。
源码分析：上面的流程分析让我们很直观地了解了线程池的工作原理，让我们再通过代 码来看看是如何实现的线程池执行任务的方法如下。
工作线程：线程池创建线程时，会将线程封装成工作线程Worker, Worker在执行完任务 后，还会循环获取工作队列里的任务来执行。我们可以从Worker类的run()方法里看到这点。
ThreadPoolExecutor中线程执行任务的示意图如图
线程池中的线程执行任务分两种情况，如下。
1)在execute()方法中创建一个线程时，会让这个线程执行当前任务。
2)这个线程执行完上图中1的任务后，会反复从BlockingQueue获取任务来执行。
向线程池提交任务
可以使用两个方法向线程池提交任务，分别为execute()和submit()方法。
execute()方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。
通过以下代码可知execute()方法输入的任务是一个Runnable类的实例。
submit()方法用于提交需要返回值的任务。线程池会返回一个future类型的对象，通过这个 future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方 法会阻塞当前线程直到任务完成，而使用get(long timeout, TimeUnit unit)方法则会阻塞当前线 程一段时间后立即返回，这时候有可能任务没有执行完。
关闭线程池
可以通过调用线程池的shutdown或shutdownNow方法来关闭线程池。它们的原理是遍历线 程池中的工作线程，然后逐个调用线程的interrupt方法来中断线程，所以无法响应中断的任务 可能永远无法终止。
但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成 STOP, 然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表。
而 shutdown只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线 程。
只要调用了这两个关闭方法中的任意一个，isShutdown方法就会返回true。当所有的任务 都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回true。至于应该调用哪 一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用shutdown方法来关闭 线程池，如果任务不一定要执行完，则可以调用shutdownNow方法。
线程池submit与异常
当一个线程池里面的线程异常后:
1、当执行方式是execute时,可以看到堆栈异常的输出原因：ThreadPoolExecutor.runWorker()方法中，task.run()，即执行我们的方法，如果异常的话会throw x;所以可以看到异常。
2、当执行方式是submit时,堆栈异常没有输出。但是调用Future.get()方法时，可以捕获到异常
原因：ThreadPoolExecutor.runWorker()方法中，task.run()，其实还会继续执行FutureTask.run()方法，再在此方法中c.call()调用我们的方法，
如果报错是setException()，并没有抛出异常。当我们去get()时，会将异常抛出。
3、不会影响线程池里面其他线程的正常执行
4、线程池会把这个线程移除掉，并创建一个新的线程放到线程池中
当线程异常，会调用ThreadPoolExecutor.runWorker()方法最后面的finally中的processWorkerExit()，会将此线程remove，并重新addworker()一个线程。
使用线程池的时候，线程因异常被中断却没有抛出任何信息呢？还有平时如果是在 main 函数里面的异常也会被抛出来，而不是像线程池这样被吞掉。
如果子线程抛出了异常，线程池会如何进行处理呢？
我提交任务到线程池的方式是: threadPoolExecutor.submit(Runnbale task); ，后面了解到使用 execute() 方式提交任务会把异常日志给打出来，这里研究一下为什么使用 submit 提交任务，在任务中的异常会被“吞掉”。
对于 submit() 形式提交的任务，我们直接看源码：
public Future submit(Runnable task) {
if (task == null) throw new NullPointerException();
// 被包装成 RunnableFuture 对象，然后准备添加到工作队列
RunnableFuture ftask = newTaskFor(task, null);
execute(ftask);
return ftask;
} 它会被线程池包装成 RunnableFuture 对象，而最终它其实是一个 FutureTask 对象，在被添加到线程池的工作队列，然后调用 start() 方法后， FutureTask 对象的 run() 方法开始运行，即本任务开始执行。
public void run() {
if (state != NEW || !UNSAFE.compareAndSwapObject(this,runnerOffset,null, Thread.currentThread()))
return;
try {
Callable c = callable;
if (c != null && state == NEW) {
V result;
boolean ran;
try {
result = c.call();
ran = true;
} catch (Throwable ex) {
// 捕获子任务中的异常
result = null;
ran = false;
setException(ex);
}
if (ran)
set(result);
}
} finally {
runner = null;
int s = state;
if (s >= INTERRUPTING)
handlePossibleCancellationInterrupt(s);
}
} 在 FutureTask 对象的 run() 方法中，该任务抛出的异常被捕获，然后在setException(ex); 方法中，抛出的异常会被放到 outcome 对象中，这个对象就是 submit() 方法会返回的 FutureTask 对象执行 get() 方法得到的结果。
但是在线程池中，并没有获取执行子线程的结果，所以异常也就没有被抛出来，即被“吞掉”了。
这就是线程池的 submit() 方法提交任务没有异常抛出的原因。
抛出异常后又会干啥呢
抛出异常后，会移出这个线程，并且视情况加入一个新的线程
/**
* 主工作程序运行循环。
* 重复地从队列中获取任务并执行它们，同时要处理以下几个问题:
*
* 1. 我们可以从一个初始任务开始，在这种情况下，我们不需要得到第一个任务。
* 否则，只要pool正在运行，我们就从getTask获取任务。如果它返回null，那么worker由于池状态或配置参数的改变而退出。
* 其他的退出来源于异常在外部代码中抛出，在这种情况下completedAbruptly持有，这通常导致processWorkerExit替换该线程。
*
* 2. 在运行任何任务之前，需要获取锁来防止其他线程池在任务执行时中断，
* 然后我们确保除非线程池停止，否则这个线程没有设置中断集。
*
* 3. 每个任务运行之前都有一个beforeExecute调用，这可能会抛出异常，
* 在这种情况下，我们导致线程死亡(以completedAbruptly true中断循环)，而不处理该任务。
*
* 4. 假设beforeExecute正常完成，我们运行任务，收集其抛出的任何异常发送到afterExecute。
* 我们分别处理RuntimeException、Error(这两个都是保证我们捕获的)和任意Throwables。
* 因为我们不能在Runnable.run中重新抛出Throwables，所以我们在退出时将它们包装在错误中(到线程的UncaughtExceptionHandler)。
* 任何抛出的异常也会保守地导致线程死亡。
*
* 5. task.run完成后，我们调用afterExecute，这也可能抛出异常，也会导致线程死亡。
* 根据JLS第14.20节，即使task.run抛出异常，这个异常也会生效。
*
* 异常机制的最终效果是，afterExecute和线程的UncaughtExceptionHandler
* 提供了我们所能提供的关于用户代码遇到的任何问题的准确信息。
*
* runWorker是线程池工作线程的全部运行逻辑，一定是工作线程来执行runWorker的。
*
* @param w the worker
*/
final void runWorker(Worker w) {
// 进入循环前，将state设置为0，使得Worker锁可以被抢。
// 循环是工作线程的主要逻辑，每次循环通过条件里的getTask()获得task来执行。当然，getTask()必然是可以阻塞等待直到从队列取得元素的。
// 执行task前，必须先消耗中断状态（如果线程已被中断），因为中断状态不清理会导致getTask()里无法阻塞。
// 并且只有在线程池状态为STOP时（task队列已空）且线程已被中断，才恢复线程的中断状态
//（这看起来可以用来保证，在当前循环执行task后下一次循环getTask()会抛出中断异常，但实际上getTask()发现STOP状态会直接返回null；
// 当然还有一种可能，就是task.run()会检测中断状态抛出中断异常）。
// 执行task前，先执行beforeExecute。如果抛出异常，会导致task.run()不执行。
// 执行task时（task.run()），可能抛出异常。
// 无论执行task时是否抛出异常，都会执行afterExecute。
// 每次循环结束前，无论前面有没有抛出异常，都会清空一些变量，并释放Worker锁，因为这次拿到的task已经执行完毕。
// 从循环结束有两个原因：
// 1. task.run()返回null了，循环正常结束（completedAbruptly为false）。
// 2. 在执行task时抛出了异常，也会结束循环（completedAbruptly为true）。无论哪种情况，当前Worker线程都会马上寿终正寝了。
// 简单的说，runWorker做的就是每次循环中从队列中取出一个task来执行，如果队列为空，那么阻塞等待直到队列非空取到task。这就是每个工作线程的工作内容。
Thread wt = Thread.currentThread();//获得当前线程对象
Runnable task = w.firstTask;//获得第一个task（这里可能为null）
w.firstTask = null;//释放引用
w.unlock(); // 此时state为0，Worker锁此时可以被抢。且此时工作线程可以被中断了
boolean completedAbruptly = true;//是否发生异常
try {
//1. 如果第一个task不为null，开始执行循环
//2. 如果第一个task为null，但从task队列里获得的task不为null，也开始循环
//3. 如果task队列获得到的也是null，那么结束循环
while (task != null || (task = getTask()) != null) {
w.lock();//执行task前，先获得锁
// 第一个表达式 (runStateAtLeast(ctl.get(), STOP) || (Thread.interrupted() && runStateAtLeast(ctl.get(), STOP)))
// 无论线程池状态是什么都会消耗掉当前线程的中断状态（如果当前线程确实被中断了），
// 并且只有线程池状态是STOP的情况下，且当前线程被中断了，才会返回true。
// 第二个表达式 !wt.isInterrupted()
// 因为第一个表达式永远会消耗掉中断状态，所以第二个表达式肯定为true
// 总之，重点在第一个表达式。
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
// 1. 如果线程池状态为STOP，且当前线程被中断，马上恢复中断状态
// 2. 如果线程池状态为其他，且当前线程被中断，仅仅消耗掉这个中断状态，不进入分支
wt.interrupt();//恢复中断状态
try {
//空实现的方法，如果抛出异常，completedAbruptly将为true
beforeExecute(wt, task);
Throwable thrown = null;
try {
task.run();//执行task
} catch (RuntimeException x) {
thrown = x; throw x;//这里抛出异常，completedAbruptly也将为true
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
//空实现方法
afterExecute(task, thrown);//task.run()抛出异常的话，至少afterExecute可以执行
}
} finally {//无论上面在beforeExecute或task.run()中抛出异常与否，最终都会执行这里
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;//上面循环是正常结束而没有抛出异常，这个变量才为false
} finally {
//无论循环正常结束(getTask返回null，completedAbruptly为false)，
//还是循环中抛出了异常(completedAbruptly为true)，都会执行这句。
//代表当前Worker马上要寿终正寝了
processWorkerExit(w, completedAbruptly);
}
}
/**
* 为垂死的工人做清理和记账工作。仅从工作线程调用。
* 除非设置了completedAbruptly，否则假定workerCount已经调整为考虑退出。
* 如果它由于用户任务异常退出，或如果少于corepoolsize工作线程正在运行，或队列非空但没有工作线程，
* 这个方法从工作线程集中移除线程，并可能终止线程池或替换工作线程。
*
* 当前线程已经从runWorker中的循环中退出，可能是因为getTask返回null，也可能是执行task时抛出了异常。
* 总之，当前worker线程已经马上要寿终正寝了，所以来调用processWorkerExit。
*
* @param w the worker
* @param completedAbruptly if the worker died due to user exception
*/
//传入Worker已经马上要寿终正寝
private void processWorkerExit(Worker w, boolean completedAbruptly) {
// 前面做了一些收尾工作，比如ctl减一，workers移除。当前worker即将要寿终正寝，但可能需要在结束前补充一个worker。
// 如果当前worker是因为抛出异常从而结束自己生命的，那么肯定补充（!completedAbruptly为false）。
// 如果当前worker是因为getTask返回null从而结束自己生命的，那么在当前线程数量不够最小线程数时，才会去补充。
// 这也解释了interruptIdleWorkers(ONLY_ONE)为什么会传播中断状态。
// 因为一个空闲的工作线程被中断后，会去执行processWorkerExit里的tryTerminate，
// 而tryTerminate里又会去调用interruptIdleWorkers(ONLY_ONE)唤醒另一个空闲线程。
if (completedAbruptly) // 如果runWorker中的循环不是正常结束的，则需要此函数来减小线程数
decrementWorkerCount(); // 否则是runWorker里的getTask做了这件事（getTask返回了null）
//此时，ctl的线程数量是不包括传入Worker了
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
//传入Worker的完成任务数量 加到 线程池的总和上去
completedTaskCount += w.completedTasks;
workers.remove(w);
} finally {
mainLock.unlock();
}
tryTerminate();//帮助Terminate
int c = ctl.get();
if (runStateLessThan(c, STOP)) {//如果状态为RUNNING或SHUTDOWN，才可能需要补充线程
//但补充前还需要判断一下
if (!completedAbruptly) {//如果传入Worker是正常结束的
//min表示线程池的最小线程数
int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
if (min == 0 && ! workQueue.isEmpty())//如果为0且队列非空，那么需要再加1
min = 1;
if (workerCountOf(c) >= min)//如果当前线程数量满足要求
return; // 那么不需要补充线程，直接返回
}
// 1. 如果传入Worker是因为抛出异常而结束，那么肯定补充
// 2. 如果传入Worker是正常结束，那么视需要而补充
addWorker(null, false);//补充一个线程
}
}线程池高级理论
为什么要把任务先放在任务队列里面，而不是把线程先拉满到最大线程数？
我说下我的个人理解。
其实经过上面的分析可以得知，线程池本意只是让核心数量的线程工作着，不论是 core 的取名，还是 keepalive 的设定，所以你可以直接把 core 的数量设为你想要线程池工作的线程数，而任务队列起到一个缓冲的作用。最大线程数这个参数更像是无奈之举，在最坏的情况下做最后的努力，去新建线程去帮助消化任务。
所以我个人觉得没有为什么，就是这样设计的，并且这样的设定挺合理。
当然如果你想要扯一扯 CPU 密集和 I/O 密集，那可以扯一扯。
原生版线程池的实现可以认为是偏向 CPU 密集的，也就是当任务过多的时候不是先去创建更多的线程，而是先缓存任务，让核心线程去消化，从上面的分析我们可以知道，当处理 CPU 密集型任务的时，线程太多反而会由于线程频繁切换的开销而得不偿失，所以优先堆积任务而不是创建新的线程。
而像 Tomcat 这种业务场景，大部分情况下是需要大量 I/O 处理的情况就做了一些定制，修改了原生线程池的实现，使得在队列没满的时候，可以创建线程至最大线程数。
如何修改原生线程池，使得可以先拉满线程数再入任务队列排队？
如果了解线程池的原理，很轻松的就知道关键点在哪，就是队列的 offer 方法。
execute 方法想必大家都不陌生，就是给线程池提交任务的方法。在这个方法中可以看到只要在 offer 方法内部判断此时线程数还小于最大线程数的时候返回 false，即可走下面 else if 中 addWorker (新增线程)的逻辑，如果数量已经达到最大线程数，直接入队即可。
详细的我们可以看看 Tomcat 中是如何定制线程的。
Tomcat 中的定制化线程池实现
public class ThreadPoolExecutor extends java.util.concurrent.ThreadPoolExecutor {}
可以看到先继承了 JUC 的线程池，然后我们重点关注一下 execute 这个方法
这里可以看到，Tomcat 维护了一个 submittedCount 变量，这个变量的含义是统计已经提交的但是还未完成的任务数量(记住这个变量，很关键)，所以只要提交一个任务，这个数就加一，并且捕获了拒绝异常，再次尝试将任务入队，这个操作其实是为了尽可能的挽救回一些任务，因为这么点时间差可能已经执行完很多任务，队列腾出了空位，这样就不需要丢弃任务。
然后我们再来看下代码里出现的 TaskQueue，这个就是上面提到的定制关键点了。
public class TaskQueue extends LinkedBlockingQueue {
private transient volatile ThreadPoolExecutor parent = null;
........
} 可以看到这个任务队列继承了 LinkedBlockingQueue，并且有个 ThreadPoolExecutor 类型的成员变量 parent ，我们再来看下 offer 方法的实现，这里就是修改原来线程池任务提交与线程创建逻辑的核心了。
从上面的逻辑可以看出是有机会在队列还未满的时候，先创建线程至最大线程数的！
再补充一下，如果对直接返回 false 就能创建线程感到疑惑的话，往上翻一翻，上面贴了原生线程池 execute 的逻辑。
然后上面的代码其实只看到 submittedCount 的增加，正常的减少在 afterExecute 里实现了。
而这个 afterExecute 在任务执行完毕之后就会调用，与之对应的还有个 beforeExecute，在任务执行之前调用。
至此，想必 Tomcat 中的定制化线程池的逻辑已经明白了。
如果线程池中的线程在执行任务的时候，抛异常了，会怎么样？
嘿嘿，细心的同学想必已经瞄到了上面的代码，task.run() 被 try catch finally包裹，异常被扔到了 afterExecute 中，并且也继续被抛了出来。
而这一层外面，还有个try finally，所以异常的抛出打破了 while 循环，最终会执行 `processWorkerExit方法
我们来看下这个方法，其实逻辑很简单，把这个线程废了，然后新建一个线程替换之。
移除了引用等于销毁了，这事儿 GC 会做的。
所以如果一个任务执行一半就抛出异常，并且你没有自行处理这个异常，那么这个任务就这样戛然而止了，后面也不会有线程继续执行剩下的逻辑，所以要自行捕获和处理业务异常。
addWorker 的逻辑就不分析了，就是新建一个线程，然后塞到 workers 里面，然后调用 start() 让它跑起来。
原生线程池的核心线程一定伴随着任务慢慢创建的吗？
并不是，线程池提供了两个方法：
prestartCoreThread：启动一个核心线程
prestartAllCoreThreads ：启动所有核心线程
不要小看这个预创建方法，预热很重要，不然刚重启的一些服务有时是顶不住瞬时请求的，就立马崩了，所以有预热线程、缓存等等操作。
线程池的核心线程在空闲的时候一定不会被回收吗？
有个 allowCoreThreadTimeOut 方法，把它设置为 true ，则所有线程都会超时，不会有核心数那条线的存在。
具体是会调用 interruptIdleWorkers 这个方法。
这里需要讲一下的是 w.tryLock() 这个方法，有些人可能会奇怪，Worker 怎么还能 lock。
Worker 是属于工作线程的封装类，它不仅实现了 Runnable 接口，还继承了 AQS。
之所以要继承 AQS 就是为了用上 lock 的状态，执行任务的时候上锁，任务执行完了之后解锁，这样执行关闭线程池等操作的时候可以通过 tryLock 来判断此时线程是否在干活，如果 tryLock 成功说明此时线程是空闲的，可以安全的回收。
与interruptIdleWorkers 对应的还有一个 interruptWorkers 方法，从名字就能看出差别，不空闲的 worker 也直接给打断了。
根据这两个方法，又可以扯到 shutdown 和 shutdownNow，就是关闭线程池的方法，一个是安全的关闭线程池，会等待任务都执行完毕，一个是粗暴的直接咔嚓了所有线程，管你在不在运行，两个方法分别调用的就是 interruptIdleWorkers() 和 interruptWorkers() 来中断线程。
这又可以引申出一个问题，shutdownNow 了之后还在任务队列中的任务咋办？眼尖的小伙伴应该已经看到了，线程池还算负责，把未执行的任务拖拽到了一个列表中然后返回，至于怎么处理，就交给调用者了！
详细就是上面的 drainQueue 方法。
这里可能又会有同学有疑问，都 drainTo 了，为什么还要判断一下队列是否为空，然后进行循环？
那是因为如果队列是 DelayQueue 或任何其他类型的队列，其中 poll 或 drainTo 可能无法删除某些元素，所以需要遍历，逐个删除它们。
线程池如何动态修改核心线程数和最大线程数？
其实之所以会有这样的需求是因为线程数是真的不好配置。
线程数=CPU核数 *（1+线程等待时间 / 线程时间运行时间）
这个比上面的更贴合与业务，还有一些理想的公式就不列了。就这个公式而言，这个线程等待时间就很难测，拿 Tomcat 线程池为例，每个请求的等待时间能知道？不同的请求不同的业务，就算相同的业务，不同的用户数据量也不同，等待时间也不同。
所以说线程数真的很难通过一个公式一劳永逸，线程数的设定是一个迭代的过程，需要压测适时调整，以上的公式做个初始值开始调试是 ok 的。
再者，流量的突发性也是无法判断的，举个例子 1 秒内一共有 1000 个请求量，但是如果这 1000 个请求量都是在第一毫秒内瞬时进来的呢？
这就很需要线程池的动态性，也是这个上面这个面试题的需求来源。
原生的线程池核心我们大致都过了一遍，不过这几个方法一直没提到，先来看看这几个方法：
我就不一一翻译了，大致可以看出线程池其实已经给予方法暴露出内部的一些状态，例如正在执行的线程数、已完成的任务数、队列中的任务数等等。
当然你可以想要更多的数据监控都简单的，像 Tomcat 那种继承线程池之后自己加呗，动态调整的第一步监控就这样搞定了！定时拉取这些数据，然后搞个看板，再结合邮件、短信、钉钉等报警方式，我们可以很容易的监控线程池的状态！
接着就是动态修改线程池配置了。
可以看到线程池已经提供了诸多修改方法来更改线程池的配置，所以李老都已经考虑到啦！
同样，也可以继承线程池增加一些方法来修改，看具体的业务场景了。同样搞个页面，然后给予负责人员配置修改即可。
所以原生线程池已经提供修改配置的方法，也对外暴露出线程池内部执行情况，所以只要我们实时监控情况，调用对应的 set 方法，即可动态修改线程池对应配置。
回答面试题的时候一定要提监控，显得你是有的放矢的。
动态修改参数的实现
先来看下设置核心线程数的方法：
随着注释看下来应该没什么问题，就是那个 k 值我说一下，李老觉得核心线程数是配置了，但是此时线程池内部是否需要这么多线程是不确定的，那么就按工作队列里面的任务数来，直接按任务数立刻新增线程，当任务队列为空了之后就终止新增。
这其实和李老设计的默认核心线程数增加策略是一致的，都是懒创建线程。
再看看设置最大线程数的方法：
没啥花头，调用的 interruptIdleWorkers 之前都分析过了。
如果要让你设计一个线程池，你要怎么设计？
这种设计类问题还是一样，先说下理解，表明你是知道这个东西的用处和原理的，然后开始 BB。基本上就是按照现有的设计来说，再添加一些个人见解。
线程池讲白了就是存储线程的一个容器，池内保存之前建立过的线程来重复执行任务，减少创建和销毁线程的开销，提高任务的响应速度，并便于线程的管理。
我个人觉得如果要设计一个线程池的话得考虑池内工作线程的管理、任务编排执行、线程池超负荷处理方案、监控。
初始化线程数、核心线程数、最大线程池都暴露出来可配置，包括超过核心线程数的线程空闲消亡配置。
任务的存储结构可配置，可以是无界队列也可以是有界队列，也可以根据配置分多个队列来分配不同优先级的任务，也可以采用 stealing 的机制来提高线程的利用率。
再提供配置来表明此线程池是 IO 密集还是 CPU 密集型来改变任务的执行策略。
超负荷的方案可以有多种，包括丢弃任务、拒绝任务并抛出异常、丢弃最旧的任务或自定义等等。
线程池埋好点暴露出用于监控的接口，如已处理任务数、待处理任务数、正在运行的线程数、拒绝的任务数等等信息。
我觉得基本上这样答就差不多了，等着面试官的追问就好。
注意不需要跟面试官解释什么叫核心线程数之类的，都懂的没必要。
当然这种开放型问题还是仁者见仁智者见智，我这个不是标准答案，仅供参考。
线程池最佳实践
线程池在实际项目的使用场景
线程池一般用于执行多个不相关联的耗时任务，没有多线程的情况下，任务顺序执行，使用了线程池的话可让多个不相关联的任务同时执行。
假设我们要执行三个不相关的耗时任务，Guide 画图给大家展示了使用线程池前后的区别。
注意：下面三个任务可能做的是同一件事情，也可能是不一样的事情。
创建线程池的方法与Executors的弊端
《阿里巴巴 Java 开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
Executors 返回线程池对象的弊端如下：
FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX_VALUE ，可能堆积大量的请求，从而导致 OOM。
CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。
说白了就是：使用有界队列，控制线程创建数量。
除了避免 OOM 的原因之外，不推荐使用 Executors提供的两种快捷的线程池的原因还有：
1 实际使用中需要根据自己机器的性能、业务场景来手动配置线程池的参数比如核心线程数、使用的任务队列、饱和策略等等。
2 我们应该显示地给我们的线程池命名，这样有助于我们定位问题。
方式一：通过构造方法实现
方式二：通过 Executor 框架的工具类 Executors 来实现
我们可以创建三种类型的 ThreadPoolExecutor：
FixedThreadPool ： 该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
SingleThreadExecutor： 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
CachedThreadPool： 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。
对应 Executors 工具类中的方法如图所示：
合理地配置线程池
很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了上下文切换成本。不清楚什么是上下文切换的话，可以看我下面的介绍。
上下文切换
多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。
上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。
Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。
常规配置
类比于实现世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。
但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。
有一个简单并且适用面比较广的公式：
CPU 密集型任务(N+1)： 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。
I/O 密集型任务(2N或者2N+1)： 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是 2N。
如何判断是 CPU 密集任务还是 IO 密集任务？
CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。但凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。
其他的办法是
线程数 = CPU 核心数 * (1 + IO 耗时/ CPU 耗时)
通过这个公式，我们可以计算出一个合理的线程数量，如果任务的平均等待时间长，线程数就随之增加，而如果平均工作时间长，也就是对于我们上面的 CPU 密集型任务，线程数就随之减少。
可以采用 APM 工具统计到每个方法的耗时，便于计算 IO 耗时和 CPU 耗时。
还有一派的计算方式是《Java虚拟机并发编程》中提出的：
线程数 = CPU 核心数 / (1 - 阻塞系数)
其中计算密集型阻塞系数为 0，IO 密集型阻塞系数接近 1，一般认为在 0.8 ~ 0.9 之间。比如 8 核 CPU，按照公式就是 2 / ( 1 - 0.9 ) = 20 个线程数
分拆任务与队列选择
如果可以拆分，将其拆分成一个CPU密集型任务 和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐量 将高于串行执行的吞吐量。如果这两个任务执行时间相差太大，则没必要进行分解。可以通过 Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数。
优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理。它可以让优先级高 的任务先执行。
如果一直有优先级高的任务提交到队列里，那么优先级低的任务可能永远不能 执行。
执行时间不同的任务可以交给不同规模的线程池来处理，或者可以使用优先级队列，让 执行时间短的任务先执行。
依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，等待的时间越 长，则CPU空闲时间就越长，那么线程数应该设置得越大，这样才能更好地利用CPU。
建议使用有界队列。有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点 儿，比如几千。有一次，我们系统里后台任务线程池的队列和线程池全满了，不断抛出抛弃任 务的异常，通过排查发现是数据库出现了问题，导致执行SQL变得非常缓慢，因为后台任务线 程池里的任务全是需要向数据库查询和插入数据的，所以导致线程池里的工作线程全部阻 塞，任务积压在线程池里。如果当时我们设置成无界队列，那么线程池的队列就会越来越多， 有可能会撑满内存，导致整个系统不可用，而不只是后台任务出现问题。当然，我们的系统所 有的任务是用单独的服务器部署的我们使用不同规模的线程池完成不同类型的任务，但是 出现这样问题时也会影响到其他任务。
美团的骚操作
美团技术团队在《Java线程池实现原理及其在美团业务中的实践》 (opens new window)这篇文章中介绍到对线程池参数实现可自定义配置的思路和方法。
美团技术团队的思路是主要对线程池的核心参数实现自定义可配置。这三个核心参数是：
corePoolSize : 核心线程数线程数定义了最小可以同时运行的线程数量。
maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。
workQueue: 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。
为什么是这三个参数？
我在这篇《新手也能看懂的线程池学习总结》 (opens new window) 中就说过这三个参数是 ThreadPoolExecutor 最重要的参数，它们基本决定了线程池对于任务的处理策略。
如何支持参数动态配置？ 且看 ThreadPoolExecutor 提供的下面这些方法。
格外需要注意的是corePoolSize， 程序运行期间的时候，我们调用 setCorePoolSize（）这个方法的话，线程池会首先判断当前工作线程数是否大于corePoolSize，如果大于的话就会回收工作线程。
另外，你也看到了上面并没有动态指定队列长度的方法，美团的方式是自定义了一个叫做 ResizableCapacityLinkedBlockIngQueue 的队列（主要就是把LinkedBlockingQueue的capacity 字段的final关键字修饰给去掉了，让它变为可变的）。
最终实现的可动态修改线程池参数效果如下。
还没看够？推荐 why神的《如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答。》 (opens new window)这篇文章，深度剖析，很不错哦！
线程池的监控
你可以通过一些手段来检测线程池的运行状态比如 SpringBoot 中的 Actuator 组件。
除此之外，我们还可以利用 ThreadPoolExecutor 的相关 API做一个简陋的监控。从下图可以看出， ThreadPoolExecutor提供了获取线程池当前的线程数和活跃线程数、已经执行完成的任务数、正在排队中的任务数等等。
下面是一个简单的 Demo。printThreadPoolStatus()会每隔一秒打印出线程池的线程数、活跃线程数、完成的任务数、以及队列中的任务数。
/**
* 打印线程池的状态
*
* @param threadPool 线程池对象
*/
public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) {
ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false));
scheduledExecutorService.scheduleAtFixedRate(() -> {
log.info("=========================");
log.info("ThreadPool Size: [{}]", threadPool.getPoolSize());
log.info("Active Threads: {}", threadPool.getActiveCount());
log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount());
log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());
log.info("=========================");
}, 0, 1, TimeUnit.SECONDS);
}
如果在系统中大量使用线程池，则有必要对线程池进行监控，方便在出现问题时，可以根 据线程池的使用状况快速定位问题。可以通过线程池提供的参数进行监控，在监控线程池的 时候可以使用以下属性。
taskCount: 线程池需要执行的任务数量。
completedTaskCount: 线程池在运行过程中已完成的任务数量，小于或等于taskCount。
largestPoolSize: 线程池里曾经创建过的最大线程数量。通过这个数据可以知道线程池是 否曾经满过。如该数值等于线程池的最大大小，则表示线程池曾经满过。
getPoolSize: 线程池的线程数量。如果线程池不销毁的话，线程池里的线程不会自动销 毁，所以这个大小只增不减。
getActiveCount: 获取活动的线程数。
通过扩展线程池进行监控。可以通过继承线程池来自定义线程池，重写线程池的 beforeExecute、after Execute和terminated方法，也可以在任务执行前、执行后和线程池关闭前执 行一些代码来进行监控。例如，监控任务的平均执行时间、最大执行时间和最小执行时间等。 这几个方法在线程池里是空方法。
建议不同类别的业务用不同的线程池
很多人在实际项目中都会有类似这样的问题：我的项目中多个业务需要用到线程池，是为每个线程池都定义一个还是说定义一个公共的线程池呢？
一般建议是不同的业务使用不同的线程池，配置线程池的时候根据当前业务的情况对当前线程池进行配置，因为不同的业务的并发以及对资源的使用情况都不同，重心优化系统性能瓶颈相关的业务。
上面的代码可能会存在死锁的情况，为什么呢？画个图给大家捋一捋。
试想这样一种极端情况：假如我们线程池的核心线程数为 n，父任务（扣费任务）数量为 n，父任务下面有两个子任务（扣费任务下的子任务），其中一个已经执行完成，另外一个被放在了任务队列中。由于父任务把线程池核心线程资源用完，所以子任务因为无法获取到线程资源无法正常执行，一直被阻塞在队列中。父任务等待子任务执行完成，而子任务等待父任务释放线程池资源，这也就造成了 "死锁"。
解决方法也很简单，就是新增加一个用于执行子任务的线程池专门为其服务。
别忘记给线程池命名
初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。
默认情况下创建的线程名字类似 pool-1-thread-n 这样的，没有业务含义，不利于我们定位问题。
给线程池里的线程命名通常有下面两种方式：
利用 guava 的 ThreadFactoryBuilder
ThreadFactory threadFactory = new ThreadFactoryBuilder()
.setNameFormat(threadNamePrefix + "-%d")
.setDaemon(true).build();
ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory)
自己实现 ThreadFactor。
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.atomic.AtomicInteger;
/**
* 线程工厂，它设置线程名称，有利于我们定位问题。
*/
public final class NamingThreadFactory implements ThreadFactory {
private final AtomicInteger threadNum = new AtomicInteger();
private final ThreadFactory delegate;
private final String name;
/**
* 创建一个带名字的线程池生产工厂
*/
public NamingThreadFactory(ThreadFactory delegate, String name) {
this.delegate = delegate;
this.name = name; // TODO consider uniquifying this
}
@Override
public Thread newThread(Runnable r) {
Thread t = delegate.newThread(r);
t.setName(name + " [#" + threadNum.incrementAndGet() + "]");
return t;
}
}
线程池自定义异常处理方法
在定义 ThreadFactory 的时候调用setUncaughtExceptionHandler方法，自定义异常处理方法。例如：
ThreadFactory namedThreadFactory = new ThreadFactoryBuilder()
.setNameFormat("judge-pool-%d")
.setUncaughtExceptionHandler((thread, throwable)-> logger.error("ThreadPool {} got exception", thread,throwable))
.build();这样，对于线程池中每条线程抛出的异常都会打下 error 日志，就不会看不到了。