线程池：第三章：线程池的手写改造和拒绝策略以及线程池配置合理线程数

根据阿里巴巴开发手册：

我们线程池使用ThreadPoolExecutor的方式进行创建，下面看底层源码：

 

有七个参数：

现在创建它：核心线程数2，同时执行的最大线程数5，多余线程存活时间1L，单位秒，阻塞队列3，默认线程工厂，拒绝策略

创建线程池：

第一种拒绝策略：AbortPolicy：超出最大线程数，直接抛出RejectedExecutionException异常阻止系统正常运行。 

运行五个线程：

 运行八个线程：

运行9个线程：

由此可以看出最大线程数为：同时执行的最大线程数+任务队列（阻塞队列）数，超过了最大线程数直接运行拒绝策略。

 

第二种拒绝策略：

“调用者运行”一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量。（谁调用了你，到达最大线程数时，你回去找调用你的人，然后听从调用你的人安排）（超出的我们能办的给你办，不能办的给你回退 ）

 

第三拒绝策略：DiscardOldestPolicy:抛弃队列中等待最久的任务，然后把当前任务加入队列中尝试再次提交当前任务

 

第四种拒绝策略：DiscardPolicy:直接丢弃任务，不予任何处理也不抛异常，如果允许任务丢失这是最好的一种方案。

线程池配置合理线程数

查看机器的核心数

 

 
------------------------

CPU密集型：cpu的核数+1，这样可以尽量减少切换

IO密集型：cpu的核数*10（一般阻塞系统是0.9）

业务场景：

1：高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换

2：并发不高、任务执行时间长的业务这就需要区分开看了：

a）假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以适当加大线程池中的线程数目，让CPU处理更多的业务

b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换

（其实从一二可以看出无论并发高不高，对于业务中是否是cpu密集还是I/O密集的判断都是需要的当前前提是你需要优化性能的前提下）

3：并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，我们的项目使用的时redis作为缓存（这类非关系型数据库还是挺好的）。增加服务器是第二步（一般政府项目的首先，因为不用对项目技术做大改动，求一个稳，但前提是资金充足），至于线程池的设置，设置参考 2 。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件（任务时间过长的可以考虑拆分逻辑放入队列等操作）对任务进行拆分和解耦。