【JavaEE初阶】线程池

📕 引言

🌳 概念

🍀ThreadPoolExecutor 类

🚩 int corePoolSize与int maximumPoolSize：

🚩 long keepAliveTime与TimeUnit nuit：

🚩 BlockingQueue workQueue：

🚩 ThreadFactory threadFactory：

🚩 RejectedExecutionHandler handler：

🎄标准库中的线程池

🏠 模拟实现线程池

🙂 多线程初阶总结

🚩 保证线程安全的大致思路：

🚩对比线程和进程

📌线程的优点

📌进程与线程的区别

📕 引言

之前呢我们对于并发编程，使用多线程就可以了，是因为线程比进程更轻量，在频繁创建和销毁的时候，更有优势，随着时代的发展，对于"频繁"二字有了新的认识。之前一个服务器 1s 处理 1k 个请求，就认为是频繁了。现在，一个服务器 1s 要处理几w的请求......

那如何优化呢？我们就引入了线程池和协程(纤程)。本篇文章就来说说线程池，对于协程暂且不表，在Java8中还不支持，后序在高版本的Java中，引入的"虚拟线程"本质上就是协程。

为哈引入线程池或者协程就能够提升效率呢？

最关键的要点，直接创建/销毁线程，是需要在用户态+内核态配合完成的工作，对于线程池/协程，只需要在用户态即可，不需要内核态的配合。

那为什么说用户态+内核态配合完成就不够高效？

例子：

🌳 概念

线程池，是一种线程的使用模式，它为了降低线程使用中频繁的创建和销毁所带来的资源消耗与代价。

通过创建一定数量的线程，让他们时刻准备就绪等待新任务的到达，而任务执行结束之后再重新回来继续待命

想象这么一个场景：

假设有一个妹子，长得很好看并且又有才华，想要谈一个对象，如果妹子和这个对象谈腻歪了，就想要换一个，成本就比较高，效率就比较低，我需要先冷暴力他，消耗他的耐心，然后再提分手，分手完毕之后，还需要下一个小哥哥一点一点培养感情，这样效率确实很低。

为了提高效率，我就和在男朋友的交往过程中，提前和其他小哥哥搞暧昧，先把感情培养到位，这样，我只要和现男友分手，后面这个暧昧的小哥就可以直接转正。这样的小哥就称为"备胎"，如果我需要频繁的更换男朋友，一个备胎不够用，就需要多搞几个，这就构成了"备胎池"。这样效率就提高了

所以字符串常量池，数据库连接池，线程池，进程池，内存池......思想都一样，用来提升效率。

线程池最核心的设计思路：复用线程，平摊线程的创建与销毁的开销代价

相比于来一个任务创建一个线程的方式，使用线程池的优势体现在如下几点：

避免了线程的重复创建与开销带来的资源消耗代价
提升了任务响应速度，任务来了直接选一个线程执行而无需等待线程的创建
线程的统一分配和管理，也方便统一的监控和调优

🍀ThreadPoolExecutor 类

标准库提供的线程池主要的类为：ThreadPoolExecutor

这个类使用起来比较复杂，构造方法很多，包含很多参数（面试考点，问这些参数是什么意思）。

在帮助手册java.util.concurrent(并发)，这里面包含了很多多线程相关的工具或者是类

构造方法：这里面有四个构造方法，仔细观察发现里面的参数，越往下越全，所以我们只需要搞清楚最后一个，前三个也就清楚了。

这里面总共有7个参数，来说说这7个参数的意思：

🚩 int corePoolSize与int maximumPoolSize：

🚩 long keepAliveTime与TimeUnit nuit：

🚩 BlockingQueue<Runnable> workQueue：

🚩 ThreadFactory threadFactory：

🚩 RejectedExecutionHandler handler：

在使用线程池并且使用有界队列的时候，如果队列满了，任务添加到线程池的时候就会有问题，那么这些溢出的任务，ThreadPoolExecutor为我们提供了拒绝任务的处理方式，以便在必要的时候按照我们的策略来拒绝任务

线程池拒绝任务的时机有以下两种：

第一种情况是当我们调用 shutdown 等方法关闭线程池后，即便此时可能线程池内部依然有没执行完的任务正在执行，但是由于线程池已经关闭，此时如果再向线程池内提交任务，就会遭到拒绝。
第二种情况是线程池没有能力继续处理新提交的任务，也就是工作已经非常饱和的时候

标准库提供了四个解决方案：

线程池任务拒绝策略实现了 RejectedExecutionHandler 接口，JDK 中自带了四种任务拒绝策略。分别是AbortPolicy、DiscardPolicy、DiscardOldestPolicy、CallerRunsPolicy。其中AbortPolicy是ThreadPoolExecutor默认使用。

1，AbortPolicy（默认）

这种拒绝策略在拒绝任务时,会直接抛出一个类RejectedExecutionException的RuntimeException，让你感知到任务被拒绝了，于是你便可以根据业务逻辑选择重试或者放弃提交等策略。

2，DiscardPolicy

这种拒绝策略正如它的名字所描述的一样，当新任务被提交后直接被丢弃掉，也不会给你任何的通知，相对而言存在一定的风险，因为我们提交的时候根本不知道这个任务会被丢弃，可能造成数据丢失。

3，DiscardOldestPolicy

如果线程池没被关闭且没有能力执行，则会丢弃任务队列中的头结点，通常是存活时间最长的任务，这种策略与第二种不同之处在于它丢弃的不是最新提交的，而是队列中存活时间最长的，这样就可以腾出空间给新提交的任务，但同理它也存在一定的数据丢失风险。

4，CallerRunsPolicy

相对而言它就比较完善了，当有新任务提交后，如果线程池没被关闭且没有能力执行，则把这个任务交于提交任务的线程执行，也就是谁提交任务，谁就负责执行任务。这样做主要有两点好处：
🎈第一点新提交的任务不会被丢弃，这样也就不会造成业务损失。
🎈第二点好处是，由于谁提交任务谁就要负责执行任务，这样提交任务的线程就得负责执行任务，而执行任务又是比较耗时的，在这段期间，提交任务的线程被占用，也就不会再提交新的任务，减缓了任务提交的速度，相当于是一个负反馈。在此期间，线程池中的线程也可以充分利用这段时间来执行掉一部分任务，腾出一定的空间，相当于是给了线程池一定的缓冲期。

总结：