【JUC并发编程】线程池及相关面试题 详解
【JUC并发编程】线程池及相关面试题 详解
参考资料：
第十二章 线程池原理 · 深入浅出Java多线程原理
两道面试题，深入线程池，连环17问
深入理解Java并发编程之线程池、工作原理、复用原理及源码分析
硬核干货：4W字从源码上分析JUC线程池ThreadPoolExecutor的实现原理
文章目录
- 【JUC并发编程】线程池及相关面试题 详解
-
-
- 1、什么是线程池？线程池有什么好处？
- 2、有几种常见的线程池?
- 3、但是为什么我说不建议大家使用这个类来创建线程池呢？
-
- Executors存在什么问题
- Executors为什么存在缺陷
- 创建线程池的正确姿势
- 4、线程池的主要参数有哪些？
- 5、线程池的工作流程？
- 6、线程池的拒绝策略有哪些？
- 7、线程池有哪几种工作队列？
- 8、如何合理设置线程池的核心线程数？
- 9、线程池优化了解吗?
- 10、如何关闭线程池?
- 11、你能设计实现一个线程池吗（BAT容易问到，小公司不会）？
- 12、线程池中的各个状态分别代表什么含义？状态之间是怎么流转的？
- 13、核心线程怎么实现一直存活？
- 14、非核心线程如何实现在 keepAliveTime 后死亡？
- 15、非核心线程能成为核心线程吗？
- 16、使用`new Thread();`这种方式去进行显式创建线程会带来什么后果？
- 17、此时线程数小于核心线程数，并且线程都处于空闲状态，现提交一个任务，是新起一个线程还是给之前创建的线程？
- 18、如何理解核心线程的 ?
- 19、线程池有几种状态？
- 20、为什么要把任务先放在任务队列里面，而不是把线程先拉满到最大线程数？
- 21、原生线程池的核心线程一定伴随着任务慢慢创建的吗？
- 22、线程池如何动态修改核心线程数和最大线程数？
- 23、如果要让你设计一个线程池，你要怎么设计？
-
1、什么是线程池？线程池有什么好处？
所谓线程池，通俗来讲，就是一个管理线程的池子。它可以容纳多个线程，其中的线程可以反复利用，省去了频繁创建线程对象的操作。
线程池的优点：
在 Java 并发编程框架中的线程池是运用场景最多的技术，几乎所有需要异步或并发执行任务的程序都可以使用线程池。在开发过程中，合理地使用线程池能够带来至少以下4个好处。
第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗；
第二：提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行；
第三：提高线程的可管理性。线程是稀缺资源，如果无限制地创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一分配、调优和监控。并发数量过多，可能会导致资源消耗过多，从而造成服务器崩溃。（主要原因）
第四：提供更强大的功能，比如延时定时线程池；
2、有几种常见的线程池?
Executors 是一个Java中的工具类。提供工厂方法来创建不同类型的线程池。
核心概念：这四个线程池的本质都是ThreadPoolExecutor对象。
newFiexedThreadPool(int Threads)：创建固定数目线程的线程池。
newCachedThreadPool()：创建一个可缓存的线程池，调用execute 将重用以前构造的线程（如果线程可用）。如果没有可用的线程，则创建一个新线程并添加到池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。
newSingleThreadExecutor()创建一个单线程化的Executor。
newScheduledThreadPool(int corePoolSize)创建一个支持定时及周期性的任务执行的线程池，多数情况下可用来替代Timer类。
3、但是为什么我说不建议大家使用这个类来创建线程池呢？
我提到的是『不建议』，但是在阿里巴巴Java开发手册中也明确指出，而且用的词是『不允许』使用Executors创建线程池。
Executors存在什么问题
在阿里巴巴Java开发手册中提到，使用Executors创建线程池可能会导致OOM(OutOfMemory ,内存溢出)，但是并没有说明为什么，那么接下来我们就来看一下到底为什么不允许使用Executors？
我们先来一个简单的例子，模拟一下使用Executors导致OOM的情况。
/**
* @author 刘宇浩
*/
public class ExecutorsDemo {
private static ExecutorService executor = Executors.newFixedThreadPool(15);
public static void main(String[] args) {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
executor.execute(new SubThread());
}
}
}
class SubThread implements Runnable {
@Override
public void run() {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
//do nothing
}
}
}
通过指定JVM参数：-Xmx8m -Xms8m 运行以上代码，会抛出OOM:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
以上代码指出，ExecutorsDemo.java的第16行，就是代码中的executor.execute(new SubThread());。
Executors为什么存在缺陷
其实，在上面的报错信息中，我们是可以看出蛛丝马迹的，在以上的代码中其实已经说了，真正的导致OOM的其实是LinkedBlockingQueue.offer方法。
如果翻看代码的话，也可以发现，其实底层确实是通过LinkedBlockingQueue实现的：
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
如果对Java中的阻塞队列有所了解的话，看到这里或许就能够明白原因了。
Java中的BlockingQueue主要有两种实现，分别是ArrayBlockingQueue 和 LinkedBlockingQueue。
ArrayBlockingQueue是一个用数组实现的有界阻塞队列，必须设置容量。
LinkedBlockingQueue是一个用链表实现的有界阻塞队列，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。
这里的问题就出在：**不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。**也就是说，如果我们不设置LinkedBlockingQueue的容量的话，其默认容量将会是Integer.MAX_VALUE。
而newFixedThreadPool中创建LinkedBlockingQueue时，并未指定容量。此时，LinkedBlockingQueue就是一个无边界队列，对于一个无边界队列来说，是可以不断的向队列中加入任务的，这种情况下就有可能因为任务过多而导致内存溢出问题。
上面提到的问题主要体现在newFixedThreadPool和newSingleThreadExecutor两个工厂方法上，并不是说newCachedThreadPool和newScheduledThreadPool这两个方法就安全了，这两种方式创建的最大线程数可能是Integer.MAX_VALUE，而创建这么多线程，必然就有可能导致OOM。
创建线程池的正确姿势
避免使用Executors创建线程池，主要是避免使用其中的默认实现，那么我们可以自己直接调用ThreadPoolExecutor的构造函数来自己创建线程池。在创建的同时，给BlockQueue指定容量就可以了。
private static ExecutorService executor = new ThreadPoolExecutor(10, 10,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue(10));
这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出java.util.concurrent.RejectedExecutionException，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。
4、线程池的主要参数有哪些？
主要参数就是下面这几个：
- corePoolSize：线程池中的核心线程数，包括空闲线程，也就是核心线程数的大小；
- maximumPoolSize：线程池中允许的最多的线程数，也就是说线程池中的线程数是不可能超过该值的；
- keepAliveTime：当线程池中的线程数大于 corePoolSize 的时候，在超过指定的时间之后就会将多出 corePoolSize 的的空闲的线程从线程池中删除；
- unit：keepAliveTime 参数的单位（常用的秒为单位）；
- workQueue：用于保存任务的队列，此队列仅保持由 executor 方法提交的任务 Runnable 任务；
- threadFactory：线程池工厂，他主要是为了给线程起一个标识。也就是为线程起一个具有意义的名称；
- handler：拒绝策略
5、线程池的工作流程？
当向线程池提交一个任务之后，线程池是如何处理这个任务的呢？下面就先来看一下它的主要处理流程。
当使用者将一个任务提交到线程池以后，线程池是这么执行的：
①首先判断核心的线程数是否已满，如果没有满，那么就去创建一个线程去执行该任务；否则请看下一步
②如果线程池的核心线程数已满，那么就继续判断任务队列是否已满，如果没满，那么就将任务放到任务队列中；否则请看下一步
③如果任务队列已满，那么就判断线程池是否已满，如果没满，那么就创建线程去执行该任务；否则请看下一步；
④如果线程池已满，那么就根据拒绝策略来做出相应的处理；
看到这里，我们再来画一张图来总结和概括下线程池的执行示意图：
6、线程池的拒绝策略有哪些？
线程池有四种默认的拒绝策略，分别为：
- AbortPolicy：这是线程池默认的拒绝策略，在任务不能再提交的时候，抛出异常，及时反馈程序运行状态。如果是比较关键的业务，推荐使用此拒绝策略，这样子在系统不能承载更大的并发量的时候，能够及时的通过异常发现；
- DiscardPolicy：丢弃任务，但是不抛出异常。如果线程队列已满，则后续提交的任务都会被丢弃，且是静默丢弃。这玩意不建议使用；
- DiscardOldestPolicy：丢弃队列最前面的任务，然后重新提交被拒绝的任务。这玩意不建议使用；
- CallerRunsPolicy：如果任务添加失败，那么主线程就会自己调用执行器中的 executor 方法来执行该任务。这玩意不建议使用；
也就是说关于线程池的拒绝策略，最好使用默认的。这样能够及时发现异常。如果上面的都不能满足你的需求，你也可以自定义拒绝策略，只需要实现 RejectedExecutionHandler 接口即可
public class CustomRejection implements RejectedExecutionHandler {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
System.out.println("你自己想怎么处理就怎么处理");
}
}
7、线程池有哪几种工作队列？
workQueue 有多种选择，在 JDK 中一共提供了 7 中阻塞对列，分别为：
- ArrayBlockingQueue ： 一个由数组结构组成的有界阻塞队列。 此队列按照先进先出（FIFO）的原则对元素进行排序。默认情况下不保证访问者公平地访问队列 ，所谓公平访问队列是指阻塞的线程，可按照阻塞的先后顺序访问队列。非公平性是对先等待的线程是不公平的，当队列可用时，阻塞的线程都可以竞争访问队列的资格。
- LinkedBlockingQueue ： 一个由链表结构组成的有界阻塞队列。 此队列的默认和最大长度为Integer.MAX_VALUE。 此队列按照先进先出的原则对元素进行排序。
- PriorityBlockingQueue ： 一个支持优先级排序的无界阻塞队列。 （虽然此队列逻辑上是无界的，但是资源被耗尽时试图执行 add 操作也将失败，导致 OutOfMemoryError）
- DelayQueue： 一个使用优先级队列实现的无界阻塞队列。 元素的一个无界阻塞队列，只有在延迟期满时才能从中提取元素
- SynchronousQueue： 一个不存储元素的阻塞队列。 一种阻塞队列，其中每个插入操作必须等待另一个线程的对应移除操作 ，反之亦然。（SynchronousQueue 该队列不保存元素）
- LinkedTransferQueue： 一个由链表结构组成的无界阻塞队列。 相对于其他阻塞队列LinkedTransferQueue多了tryTransfer和transfer方法。
- LinkedBlockingDeque： 一个由链表结构组成的双向阻塞队列。 是一个由链表结构组成的双向阻塞队列
在以上的7个队列中，线程池中常用的是ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue
队列中的常用的方法如下：
| 类型 | 方法 | 含义 | 特点 |
|---|---|---|---|
| 抛异常 | add | 添加一个元素 | 如果队列满，抛出异常 IllegalStateException |
| 抛异常 | remove | 返回并删除队列的头节点 | 如果队列空，抛出异常 NoSuchElementException |
| 抛异常 | element | 返回队列头节点 | 如果队列空，抛出异常 NoSuchElementException |
| 不抛异常，但是不阻塞 | offer | 添加一个元素 | 添加成功，返回 true，添加失败，返回 false |
| 不抛异常，但是不阻塞 | poll | 返回并删除队列的头节点 | 如果队列空，返回 null |
| 不抛异常，但是不阻塞 | peek | 返回队列头节点 | 如果队列空，返回 null |
| 阻塞 | put | 添加一个元素 | 如果队列满，阻塞 |
| 阻塞 | take | 返回并删除队列的头节点 | 如果队列空，阻塞 |
8、如何合理设置线程池的核心线程数？
线程池数量的确定一直是困扰着程序员的一个难题，大部分程序员在设定线程池大小的时候就是随心而定。
很多人甚至可能都会觉得把线程池配置过大一点比较好！我觉得这明显是有问题的。就拿我们生活中非常常见的一例子来说：并不是人多就能把事情做好，增加了沟通交流成本。你本来一件事情只需要 3 个人做，你硬是拉来了 6 个人，会提升做事效率嘛？我想并不会。 线程数量过多的影响也是和我们分配多少人做事情一样，对于多线程这个场景来说主要是增加了上下文切换成本。不清楚什么是上下文切换的话，可以看我下面的介绍。
上下文切换：
多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。
上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。
Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。
类比于现实世界中的人类通过合作做某件事情，我们可以肯定的一点是线程池大小设置过大或者过小都会有问题，合适的才是最好。
如果我们设置的线程池数量太小的话，如果同一时间有大量任务/请求需要处理，可能会导致大量的请求/任务在任务队列中排队等待执行，甚至会出现任务队列满了之后任务/请求无法处理的情况，或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的！ CPU 根本没有得到充分利用。
但是，如果我们设置线程数量太大，大量线程可能会同时在争取 CPU 资源，这样会导致大量的上下文切换，从而增加线程的执行时间，影响了整体执行效率。
在实际的开发中，我们需要根据任务的性质（IO是否频繁？）来决定我们创建的核心的线程数的大小，实际上可以从以下的一个角度来分析：
- 任务的性质：CPU密集型任务、IO密集型任务和混合型任务；
- 任务的优先级：高、中和低；
- 任务的执行时间：长、中和短；
- 任务的依赖性：是否依赖其他系统资源，如数据库连接；
性质不同的任务可以用不同规模的线程池分开处理。分为CPU密集型和IO密集型。
CPU密集型任务应配置尽可能小的线程，如配置 Ncpu+1个线程的线程池。(可以通过Runtime.getRuntime().availableProcessors()来获取CPU物理核数)
IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程，如 2*Ncpu。
优先级不同的任务可以使用优先级队列 PriorityBlockingQueue来处理。它可以让优先级高的任务先执行（注意：如果一直有优先级高的任务提交到队列里，那么优先级低的任务可能永远不能执行）
执行时间不同的任务可以交给不同规模的线程池来处理，或者可以使用优先级队列，让执行时间短的任务先执行。依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，等待的时间越长，则 CPU 空闲时间就越长，那么线程数应该设置得越大，这样才能更好地利用CPU。
建议使用有界队列。有界队列能增加系统的稳定性和预警能力，可以根据需要设大一点。方式因为提交的任务过多而导致 OOM；
9、线程池优化了解吗?
1）用ThreadPoolExecutor自定义线程池，看线程是的用途，如果任务量不大，可以用无界队列，如果任务量非常大，要用有界队列，防止OOM
2）如果任务量很大，还要求每个任务都处理成功，要对提交的任务进行阻塞提交，重写拒绝机制，改为阻塞提交。保证不抛弃一个任务
3）最大线程数一般设为2N+1最好，N是CPU核数
4）核心线程数，看应用，如果是任务，一天跑一次，设置为0，合适，因为跑完就停掉了，如果是常用线程池，看任务量，是保留一个核心还是几个核心线程数
5）如果要获取任务执行结果，用CompletionService，但是注意，获取任务的结果的要重新开一个线程获取，如果在主线程获取，就要等任务都提交后才获取，就会阻塞大量任务结果，队列过大OOM，所以最好异步开个线程获取结果。
10、如何关闭线程池?
其实，如果优雅的关闭线程池是一个令人头疼的问题，线程开启是简单的，但是想要停止却不是那么容易的。通常而言， 大部分程序员都是使用 jdk 提供的两个方法来关闭线程池，他们分别是：shutdown 或 shutdownNow；
通过调用线程池的 shutdown 或 shutdownNow 方法来关闭线程池。它们的原理是遍历线程池中的工作线程，然后逐个调用线程的 interrupt 方法来中断线程（PS：中断，仅仅是给线程打上一个标记，并不是代表这个线程停止了，如果线程不响应中断，那么这个标记将毫无作用），所以无法响应中断的任务可能永远无法终止。
但是它们存在一定的区别，shutdownNow首先将线程池的状态设置成 STOP，然后尝试停止所有的正在执行或暂停任务的线程，并返回等待执行任务的列表，而 shutdown 只是将线程池的状态设置成SHUTDOWN状态，然后中断所有没有正在执行任务的线程。
只要调用了这两个关闭方法中的任意一个，isShutdown 方法就会返回 true。当所有的任务都已关闭后，才表示线程池关闭成功，这时调用isTerminaed方法会返回 true。至于应该调用哪一种方法来关闭线程池，应该由提交到线程池的任务特性决定，通常调用 shutdown方法来关闭线程池，如果任务不一定要执行完，则可以调用 shutdownNow 方法。
这里推荐使用稳妥的 shutdownNow 来关闭线程池，至于更优雅的方式可以参考**并发编程设计模式中的两阶段终止模式。
11、你能设计实现一个线程池吗（BAT容易问到，小公司不会）？
12、线程池中的各个状态分别代表什么含义？状态之间是怎么流转的？
线程池目前有5个状态：
RUNNING：接受新任务并处理排队的任务。
SHUTDOWN：不接受新任务，但处理排队的任务。
STOP：不接受新任务，不处理排队的任务，并中断正在进行的任务。
TIDYING：所有任务都已终止，workerCount 为零，线程转换到 TIDYING 状态将运行 terminated() 钩子方法。
TERMINATED：terminated() 已完成。
13、核心线程怎么实现一直存活？
阻塞队列方法有四种形式，它们以不同的方式处理操作，如下表。
核心线程在获取任务时，通过阻塞队列的 take() 方法实现的一直阻塞（存活）。
14、非核心线程如何实现在 keepAliveTime 后死亡？
原理同上，也是利用阻塞队列的方法，在获取任务时通过阻塞队列的 poll(time,unit) 方法实现的在延迟死亡。
15、非核心线程能成为核心线程吗？
虽然我们一直讲着核心线程和非核心线程，但是其实线程池内部是不区分核心线程和非核心线程的。只是根据当前线程池的工作线程数来进行调整，因此看起来像是有核心线程于非核心线程。
16、使用new Thread();这种方式去进行显式创建线程会带来什么后果？
1. OOM： 如果当前方法突遇高并发情况，假设此时来了1000个请求，而按传统的网络模型是BIO，此时服务器会开1000个线程来处理这1000个请求（不考虑WEB容器的最大线程数配置），当1000个请求执行时又会发现此方法中存在new Thread();创建线程，此时每个执行请求的线程又会创建一个线程，此时就会出现1000*2=2000个线程的情况出现，而在一个程序中创建线程是需要向JVM申请内存分配的，但是此时大量线程在同一瞬间向JVM申请分配内存，此时会很容易造成内存溢出（OOM）的情况发生。
2. 资源开销与耗时： Java对象的生命周期大致包括三个阶段：对象的创建，对象的使用，对象的清除。因此，对象的生命周期长度可用如下的表达式表示：Object = O1 + O2 +O3。其中O1表示对象的创建时间，O2表示对象的使用时间，而O3则表示其清除（垃圾回收）时间。由此，我们可以看出，只有O2是真正有效的时间，而O1、O3则是对象本身的开销。当我们去创建一个线程时也是一样，因为线程在Java中其实也是一个Thread类的实例，所以对于线程而言，其实它的创建（申请内存分配、JVM向OS提交线程映射进程申请、OS真实线程映射）和销毁对资源是开销非常大的并且非常耗时的。
3. 不可管理性： 对于new Thread();的显示创建出来的线程是无法管理的，一旦CPU调度成功，此线程的可管理性几乎为零。
17、此时线程数小于核心线程数，并且线程都处于空闲状态，现提交一个任务，是新起一个线程还是给之前创建的线程？
李老是这样说的：If fewer than corePoolSize threads are running, try to start a new thread with the given command as its first task.
我觉得把 threads are running 去了，更合理一些，此时线程池会新起一个线程来执行这个新任务，不管老线程是否空闲。
18、如何理解核心线程的 ?
从上一个问题可以看出，线程池虽说默认是懒创建线程，但是它实际是想要快速拥有核心线程数的线程。核心线程指的是线程池承载日常任务的中坚力量，也就是说本质上线程池是需要这么些数量的线程来处理任务的，所以在懒中又急着创建它。
而最大线程数其实是为了应付突发状况。
举个装修的例子，正常情况下施工队只要 5 个人去干活，这 5 人其实就是核心线程，但是由于工头接的活太多了，导致 5 个人在约定工期内干不完，所以工头又去找了 2 个人来一起干，所以 5 是核心线程数，7 是最大线程数。
平时就是 5 个人干活，特别忙的时候就找 7 个，等闲下来就会把多余的 2 个辞了。
看到这里你可能会觉得核心线程在线程池里面会有特殊标记？
并没有，不论是核心还是非核心线程，在线程池里面都是一视同仁，当淘汰的时候不会管是哪些线程，反正留下核心线程数个线程即可。
19、线程池有几种状态？
注解说的很明白，我再翻译一下：
- RUNNING：能接受新任务，并处理阻塞队列中的任务
- SHUTDOWN：不接受新任务，但是可以处理阻塞队列中的任务
- STOP：不接受新任务，并且不处理阻塞队列中的任务，并且还打断正在运行任务的线程，就是直接撂担子不干了！
- TIDYING：所有任务都终止，并且工作线程也为0，处于关闭之前的状态
- TERMINATED：已关闭。
20、为什么要把任务先放在任务队列里面，而不是把线程先拉满到最大线程数？
我说下我的个人理解。
其实经过上面的分析可以得知，线程池本意只是让核心数量的线程工作着，不论是 core 的取名，还是 keepalive 的设定，所以你可以直接把 core 的数量设为你想要线程池工作的线程数，而任务队列起到一个缓冲的作用。最大线程数这个参数更像是无奈之举，在最坏的情况下做最后的努力，去新建线程去帮助消化任务。
所以我个人觉得没有为什么，就是这样设计的，并且这样的设定挺合理。
当然如果你想要扯一扯 CPU 密集和 I/O 密集，那可以扯一扯。
原生版线程池的实现可以认为是偏向 CPU 密集的，也就是当任务过多的时候不是先去创建更多的线程，而是先缓存任务，让核心线程去消化，从上面的分析我们可以知道，当处理 CPU 密集型任务的时，线程太多反而会由于线程频繁切换的开销而得不偿失，所以优先堆积任务而不是创建新的线程。
而像 Tomcat 这种业务场景，大部分情况下是需要大量 I/O 处理的情况就做了一些定制，修改了原生线程池的实现，使得在队列没满的时候，可以创建线程至最大线程数。
21、原生线程池的核心线程一定伴随着任务慢慢创建的吗？
并不是，线程池提供了两个方法：
- prestartCoreThread：启动一个核心线程
- prestartAllCoreThreads ：启动所有核心线程
不要小看这个预创建方法，预热很重要，不然刚重启的一些服务有时是顶不住瞬时请求的，就立马崩了，所以有预热线程、缓存等等操作。
22、线程池如何动态修改核心线程数和最大线程数？
其实之所以会有这样的需求是因为线程数是真的不好配置。
你可能会在网上或者书上看到很多配置公式，比如：
- CPU 密集型的话，核心线程数设置为 CPU核数+1
- I/O 密集型的话，核心线程数设置为 2*CPU核数
比如：
线程数=CPU核数 *（1+线程等待时间 / 线程时间运行时间）
这个比上面的更贴合与业务，还有一些理想的公式就不列了。就这个公式而言，这个线程等待时间就很难测，拿 Tomcat 线程池为例，每个请求的等待时间能知道？不同的请求不同的业务，就算相同的业务，不同的用户数据量也不同，等待时间也不同。
所以说线程数真的很难通过一个公式一劳永逸，线程数的设定是一个迭代的过程，需要压测适时调整，以上的公式做个初始值开始调试是 ok 的。
再者，流量的突发性也是无法判断的，举个例子 1 秒内一共有 1000 个请求量，但是如果这 1000 个请求量都是在第一毫秒内瞬时进来的呢？
这就很需要线程池的动态性，也是这个上面这个面试题的需求来源。
原生的线程池核心我们大致都过了一遍，不过这几个方法一直没提到，先来看看这几个方法：
我就不一一翻译了，大致可以看出线程池其实已经给予方法暴露出内部的一些状态，例如正在执行的线程数、已完成的任务数、队列中的任务数等等。
当然你可以想要更多的数据监控都简单的，像 Tomcat 那种继承线程池之后自己加呗，动态调整的第一步监控就这样搞定了！定时拉取这些数据，然后搞个看板，再结合邮件、短信、钉钉等报警方式，我们可以很容易的监控线程池的状态！
接着就是动态修改线程池配置了。
可以看到线程池已经提供了诸多修改方法来更改线程池的配置，所以李老都已经考虑到啦！
同样，也可以继承线程池增加一些方法来修改，看具体的业务场景了。同样搞个页面，然后给予负责人员配置修改即可。
所以原生线程池已经提供修改配置的方法，也对外暴露出线程池内部执行情况，所以只要我们实时监控情况，调用对应的 set 方法，即可动态修改线程池对应配置。
23、如果要让你设计一个线程池，你要怎么设计？
这种设计类问题还是一样，先说下理解，表明你是知道这个东西的用处和原理的，然后开始 BB。基本上就是按照现有的设计来说，再添加一些个人见解。
线程池讲白了就是存储线程的一个容器，池内保存之前建立过的线程来重复执行任务，减少创建和销毁线程的开销，提高任务的响应速度，并便于线程的管理。
我个人觉得如果要设计一个线程池的话得考虑池内工作线程的管理、任务编排执行、线程池超负荷处理方案、监控。
初始化线程数、核心线程数、最大线程池都暴露出来可配置，包括超过核心线程数的线程空闲消亡配置。
任务的存储结构可配置，可以是无界队列也可以是有界队列，也可以根据配置分多个队列来分配不同优先级的任务，也可以采用 stealing 的机制来提高线程的利用率。
再提供配置来表明此线程池是 IO 密集还是 CPU 密集型来改变任务的执行策略。
超负荷的方案可以有多种，包括丢弃任务、拒绝任务并抛出异常、丢弃最旧的任务或自定义等等。
线程池埋好点暴露出用于监控的接口，如已处理任务数、待处理任务数、正在运行的线程数、拒绝的任务数等等信息。
说，再添加一些个人见解。
线程池讲白了就是存储线程的一个容器，池内保存之前建立过的线程来重复执行任务，减少创建和销毁线程的开销，提高任务的响应速度，并便于线程的管理。
我个人觉得如果要设计一个线程池的话得考虑池内工作线程的管理、任务编排执行、线程池超负荷处理方案、监控。
初始化线程数、核心线程数、最大线程池都暴露出来可配置，包括超过核心线程数的线程空闲消亡配置。
任务的存储结构可配置，可以是无界队列也可以是有界队列，也可以根据配置分多个队列来分配不同优先级的任务，也可以采用 stealing 的机制来提高线程的利用率。
再提供配置来表明此线程池是 IO 密集还是 CPU 密集型来改变任务的执行策略。
超负荷的方案可以有多种，包括丢弃任务、拒绝任务并抛出异常、丢弃最旧的任务或自定义等等。
线程池埋好点暴露出用于监控的接口，如已处理任务数、待处理任务数、正在运行的线程数、拒绝的任务数等等信息。
我觉得基本上这样答就差不多了，等着面试官的追问就好。