开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第3天，点击查看活动详情
深入理解线程池及相关面试题
11、你能设计实现一个线程池吗（BAT容易问到，小公司不会）？
12、线程池中的各个状态分别代表什么含义？状态之间是怎么流转的？
14、非核心线程如何实现在 keepAliveTime 后死亡？
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、如何合理设置线程池的核心线程数？
在实际的开发中，我们需要根据任务的性质（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、非核心线程能成为核心线程吗？
虽然我们一直讲着核心线程和非核心线程，但是其实线程池内部是不区分核心线程和非核心线程的。只是根据当前线程池的工作线程数来进行调整，因此看起来像是有核心线程于非核心线程。
