JUC-线程池

一、为什么使用自定义线程池？

首先，在实际生产中肯定是要使用线程池的，而且要自定义线程池，为什么呢？这点参考阿里巴巴开发手册

 

二、ThreadPoolExecutor七大参数

我们先来看一下ThreadPoolExecutor的七大参数

 

int corePoolSize：核心线程数大小
int maximumPoolSize：最大线程数
long keepAliveTime：空闲线程存活时间
TimeUnit unit：keepAliveTime的单位
BlockingQueue<Runnable> workQueue：指定阻塞队列
ThreadFactory threadFactory：创建线程的工厂
RejectedExecutionHandler handler：拒绝策略

现在看不懂没关系，我们先来看一下执行流程：

三、执行流程：

1.在创建了线程池后，等待提交过来的任务请求。
2.当调用execute（）方法添加一个请求任务时，线程池会做如下判断：
    2.1 如果正在运行的线程数量小于corePoolSize，那么马上创建线程运行这个任务。
    2.2 如果正在运行的线程数量大于或等于corePoolSize，那么将这个任务放入队列。
    2.3 如果这个时候队列满了且正在运行的线程数量还小于maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务。
    2.4 如果队列满了且正在运行的线程数量大于或等于maximumPoolSize，那么线程池会启动饱和拒线程无事可做绝策略来执行。
3.当一个线程完成任务时，它会从队列中取下一个任务来执行。
4.当一个线程超过一定的时间（keepAlilveTime）时，线程池会判断：
    如果当前运行的线程数大于corePoolSize，那么这个线程就被停掉。
    所以线程池的所有任务完成后它
最终会收缩到corePoolSize的大小。

JDK内置的拒绝策略：
AbortPolicy（默认）：直接抛出RejectedExecutionException异常阻止系统正常运行。

CallerRunsPolicy：“调用者运行”一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量。

DiscardOldestPolicy：抛弃队列中等待最久的任务，然后把当前任务加入队列中尝试再次提交当前任务。 

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

四、如何合理配置线程池？

CPU密集型

CPU密集型是指该任务需要大量的运算，而没有阻塞CPU一直全速运行，CPU密集任务只有在真正的多核CPU上才可能得到加速（通过多线程）

CPU密集型任务配置尽可能少的线程数量：

一般公式：CPU核数+1个线程的线程池

IO密集型

方案一：

 由于IO密集型任务线程并不是一直执行任务，则应配置尽可能多的线程，如CPU核数*2

方案二：

O密集型，即该任务需要大量的IO，即大量的阻塞。
 
在单线程上运行IO密集型的任务会导致浪费大量的CPU运算能力浪费在等待。
所以IO密集型任务中使用多线程可以大大的加速程序运行，即使在单核CPU上，这种加速主要就是利用了被浪费掉的阻塞时间。
 
IO密集型时，大部分线程都阻塞，故需要多配置线程数：
参考公式：CPU核数/1-阻塞系数  阻塞系数在0.8-0.9之间。