前提常识🧀
上一篇咱们简略介绍了下线程池的一些根本内容，不分明或者想回顾的同学能够点进主页里查看，或者前面把链接🔗贴在评论里。咱们这篇次要来解决上一篇最初提出的问题：依据我的项目，本人来设置适合的参数。这个适合到底要怎么来定义？且往下看。
工作队列 workQueue 和饱和策略 handler 什么时候退场？
首先这里有几道常常考的线程池面试题：
- 简略介绍下线程池，外围数从 corePoolSize 到 maximumPoolSize 的变动过程？
- 线程池在什么时机会执行饱和策略？
- 当线程池的工作队列满之后，就会执行对应的饱和策略吗？
这些问题其实说到底都是在考线程池的执行步骤，当你弄懂这些机会和条件后，我置信你能够死记硬背整套流程。
咱们这里先引入流程图看一下：
只看流程图可能不容易了解，咱们上面用一个示例来演示一下整个流程：
首先咱们假如几个参数，corePoolSize 外围线程为 5，maximumPoolSize 最大线程数为 10，workQueue 工作队列的容量为 20，还须要用 activeCount 来示意正在工作的线程（上面简写为工作线程），为了兜底，所以假如工作始终在增加，因为很耗时，程序 hold 不住，始终到执行饱和策略的环节。
- 假如一直地有工作进来，程序就会减少工作线程来解决工作，即 activeCount 减少，会始终减少到 corePoolSize，直到满足第一个条件“外围线程池已满”，即 activeCount=corePoolSize=5。
- 这时再追加工作，程序就会把工作放进工作队列 workQueue，工作线程解决完当前任务，就会按 FIFO 先入先出的程序，从工作队列 workQueue 里拿出工作持续做；随着工作的放入，workQueue.size()会逐步增大，始终到满足第二个条件“工作队列已满”，即 workQueue.size()=20，activeCount 此时仍为 5。
- 再持续追加工作，程序就会在 corePoolSize 的基数上持续减少工作线程，即 activeCount 从 5 开始减少，始终到满足第三个条件“最大线程池已满”，即 activeCount=maximumPoolSize=10。
-
此时咱们看一下参数值，activeCount=maximumPoolSize=10，workQueue.size()=20，能满的曾经全满了，示意程序曾经达到了最大的下限，前面再追加的工作就会去执行饱和策略。
饱和策略有哪些？哪个更适宜我？
咱们先来回顾下饱和策略的意义——因为达到线程边界和队列容量而阻塞执行时应用的处理程序。
能够简略地用一句话来解释：工作队列满 & 工作线程数曾经减少到最大外围数，此时再新增进工作，便会对工作执行对应的解决。AbortPolicy
Abort-> 退出、终止；满足条件时会间接 抛出 RejectedExecutionException 异样 ，它也是 ThreadPoolExecutor 默认的饱和策略；但同时因为他的简略粗犷，程序可能会因而中断，所以尽管是默认的饱和策略，但如果要用， 务必做好异样解决。
CallerRunsPolicy
满足条件时，会间接调用以后主线程去执行工作 ，比方你在 main 办法执行了线程池， 策略的毛病就是可能会阻塞主线程，影响性能。
DiscardPolicy
Discard-> 抛弃，摈弃；这个是最简略粗犷的饱和策略，间接扔掉，满了之后再来的工作通通扔掉！对一些不重要，或者时效性比完整性优先级高的工作还是挺好用的，但如果你对工作的完整性要求高，不倡议应用。
DiscardOldestPolicy
比上个策略多了一个 oldest，意思就是 FIFO 先入先出，当满足条件时，会优先抛弃队列里最旧即最早的工作数据，所以同样的，如果你对工作的完整性要求高，不倡议应用。
这么比拟下来，置信你心里曾经有了答案：
1. 如果你对工作的完整性要求很高，一条数据都不能丢，比对性能的要求高，那适合的抉择就是 CallerRunsPolicy。
2. 如果你对性能要求很高，数据少或多都还能承受，就能够抉择其余三个饱和策略，抛弃或者对异样进行解决。
你可能会说：性能和完整性，我全都要！
那怎么办呢？有什么方法吗？
我的答案是：当然有，它既然叫饱和策略，必定是满足条件后才会走到这一步，相当于最初的保底措施，所以在肯定状况下，如果依据程序配好了其余参数，是基本不会走到饱和策略这一步的，咱们要做的就是：调整好其余参数，饱和策略是最初的底牌，尽量不要触发。
外围线程数和最大线程数到底设置多少？
从下面一系列介绍中，咱们晓得工作队列和饱和策略都有了举荐，但其实大家伙最关怀也是最纳闷的就是外围线程数和最大线程数的设置。
你可能在这之前翻过很多文章，有人说设置为服务器外围数 N，有人说应该是服务器外围数 N +1，有人说要判断是 I / O 密集型就 2N，计算密集型的话就 N +1，都很有理论依据，我已经也为这个所苦恼。
其实连带的还有一些问题，比方每台服务器的状况不一样，有的可能同时跑得有 tomcat，有的可能还有有别的服务，这个时候下面的实践配置是否还适宜咱们？
在通过翻查无数次的材料与文章后，一篇美团在 2020 年公布的名为《Java 线程池实现原理及其在美团业务中的实际》的文章让我眼前一亮：既然参数在每个服务器上都不确定，那我改成动静配置的不就能够了吗？不够我就加，多了我就减。
惋惜美团只提供了思路，并没有把代码开源进去（行了吧，还要啥自行车？
然而并不障碍网上的大佬多，曾经有集体开发者把这套逻辑整理出来并开源，没错，我也曾经上车了，真香！如果你想理解，能够搜寻“动静线程池配置”这些关键词，我在这里就不打广告了。
JOJO！这是我最初的我的项目示例了！
拿我本人的经验举个例子，阿里云 4 核 8G 的机器，单机工作的峰值 QPS 大略为 2000 左右，尽管不高，但因为线程池执行的工作都是从别家服务器获取响应，所以容易沉积，设置了最大超时工夫 200ms。
最早一版的配置是 5 /16/2000（corePoolSize/maximumPoolSize/workQueue.capacity），无奈不到高峰期就报警。
后连忙调整参数到 8 /16/2000，过后倒是不报警了，但在前面减少了策略配置后（即并发任务量减少）又呈现了报警。
后调整到 16/32/2000，仍旧报警，没错，不光 N +1、2N，都曾经 N^2，它还是报警。
这时我意识到很多状况，可能是网络问题，可能是因为服务还有其余的线程池，也可能是曾经到了线程池性能的瓶颈，所以并没有对参数进行进一步的调整。
但玄学的事件产生了：在这波报警后，前面就再也没有产生过报警了，也察看了线程池日志，发现工作线程 activeCount 最大也只到了 16，2000 容量的工作队列也只用到几十到一百多个，所有如同都归于了平静，于是参数也没有再进行批改了，仿佛曾经找到了最合适的参数。
好的，如果你看到这里，那么当初这个例子曾经是你的了。
最初的倡议
- 在面试时，记住八股文，晓得 I / O 密集型和计算密集型的理论值场景，但在跟面试官讲述时能够加上本人我的项目的例子，切实没有就能够说下面这个。
-
在理论的我的项目使用中，联合我的项目状况，最好加上动静线程池配置。
写在最初的最初
其实这篇和上篇是一口气写下来，但因为篇幅起因离开，所以倡议肯定要连贯地看下来。
在我看来如果可能将两篇内容都 get 到，对你应用线程池和跟面试官掰扯一些根本题，都会有肯定的帮忙；如果先看完这两篇，那么我举荐你接着去看美团官网的文章，我感觉算是一记增强针。
其实线程池可掰扯的货色只有这些吗？其实文章很多中央都没有点透，甚至有些疑难，比方：饱和策略只有这几个吗？有没有别的？我能够马上答复你：有！别的框架甚至都把线程池玩出了花，比方像 dubbo 的饱和策略就是会新建一条新线程来执行工作、比方 tomcat 的线程池外围数由 core 到 max 变动条件就跟 jdk 的不一样，总而言之，也是每个框架用了最合乎本人的逻辑，如果有下一篇的话，可能就会唠唠这些吧，嘻嘻~
如果你能有所播种，那么我会很开心的~ 如果能够点赞评论珍藏分享，那么我的能源会更足的，谢谢大家~