[Java 并发]详解 ThreadPoolExecutor

Bertha 。 2023-02-16 15:28 12阅读 0赞

ThreadPoolExecutor 可能在别的地方已经看过好多了,那我就尽量讲点儿不一样的知识出来

# 为什么要用线程池 #

你有没有这样的疑惑,为什么要用线程池呢?可能你会说,我可以复用已经创建的线程呀;线程是个重量级对象,为了避免频繁创建和销毁,使用线程池来管理最好了  
没毛病,各位都很懂哈~  
不过使用线程池还有一个重要的点:可以控制并发的数量.如果并发数量太多了,导致消耗的资源增多,直接把服务器给搞趴下了,肯定也是不行的

咱们再看看 ThreadPoolExecutor ,把这三个单词分开看, `Thread 线程`, `Pool 池`, `Executor` 执行者.如果连起来的话,是线程池执行者  
所以呢, ThreadPoolExecutor 它强调的是 `Executor` ,而不是一般意义上的池化资源

# 绕不过去的几个参数 #

提到 ThreadPoolExecutor 那么你的小脑袋肯定会想到那么几个参数,咱们来瞅瞅源码(我就直接放有 7 个参数的那个方法了):

public ThreadPoolExecutor(int corePoolSize,
                                int maximumPoolSize,
                                long keepAliveTime,
                                TimeUnit unit,
                                BlockingQueue<Runnable> workQueue,
                                ThreadFactory threadFactory,
                                RejectedExecutionHandler handler)

咱们分别来看:

*  corePoolSize :  
    核心线程数,在线程池中有两种线程,核心线程和非核心线程.在线程池中的核心线程,就算是它什么都不做,也会一直在线程池中,除非设置了 `allowCoreThreadTimeOut` 参数
 *  maximumPoolSize:  
    线程池能够创建的最大线程数.这个值 = 核心线程数 + 非核心线程数
 *  keepAliveTime & unit :  
    线程池是可以撤销线程的,那么什么时候撤销呢?一个线程如果在一段时间内,都没有执行任务,那说明这个线程很闲啊,那是不是就可以把它撤销掉了?  
    所以呢,如果一个线程不是核心线程,而且在 keepAliveTime & unit 这段时间内,还没有干活,那么很抱歉,只能请你走人了  
    核心线程就算是很闲,也不会将它从线程池中清除,没办法谁让它是 `core` 线程呢~
 *  workQueue :  
    工作队列,这个队列维护的是等待执行的 Runnable 任务对象  
    常用的几个队列: LinkedBlockingQueue , ArrayBlockingQueue , SynchronousQueue , DelayQueue  
    大厂的编码规范,相信各位都知道,并不建议使用 Executors ,最重要的一个原因就是: Executors 提供的很多方法默认使用的都是无界的 LinkedBlockingQueue ,在高负载情况下,无界队列很容易就导致 OOM ,而 OOM 会让所有请求都无法处理,所以在使用时,**强烈建议使用有界队列**,因为如果你使用的是有界队列的话,当线程数量太多时,它会走拒绝策略
 *  threadFactory :  
    创建线程的工厂,用来批量创建线程的.如果不指定的话,就会创建一个默认的线程工厂
 *  handler :  
    拒绝处理策略.在 workQueue 那里说了,如果使用的是有界队列,那么当线程数量大于最大线程数的时候,拒绝处理策略就起到作用了  
    常用的有四种处理策略: 
    
     *  AbortPolicy :默认的拒绝策略,会丢弃任务并抛出 RejectedExecutionException 异常
     *  CallerRunsPolicy :提交任务的线程,自己去执行这个任务
     *  DiscardOldestPolicy :直接丢弃新来的任务,也没有任何异常抛出
     *  DiscardOldestPolicy :丢弃最老的任务,然后将新任务加入到工作队列中

默认拒绝策略是 AbortPolicy ,会 throw RejectedExecutionException 异常,但是这是一个运行时异常,对于运行时异常编译器不会强制 catch 它,所以就会比较容易忽略掉错误.  
所以,如果线程池处理的任务非常重要,**尽量自定义自己的拒绝策略**

# 线程池的几个状态 #

这篇文章开始我就说了,希望能写出一点儿不一样的东西,那咱们就从源码撸一撸  
撸啥呢,源码那么多,总不能毫无目的的撸吧?  
咱们来吧线程池的 5 种状态来撸一撸  
在源码中,我们能够很明显看到定义的 5 种状态:

private static final int RUNNING    = -1 << COUNT_BITS;
    private static final int SHUTDOWN   =  0 << COUNT_BITS;
    private static final int STOP       =  1 << COUNT_BITS;
    private static final int TIDYING    =  2 << COUNT_BITS;
    private static final int TERMINATED =  3 << COUNT_BITS;

同时,使用 AtomicInteger 修饰的变量 ctl 来控制线程池的状态,而 ctl 保存了 2 个变量:一个是 rs 即 runState ,线程池的运行状态;一个是 wc 即 workerCount ,线程池中活动线程的数量

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
    private static int ctlOf(int rs, int wc) {  return rs | wc; }

*  线程池创建之后就处于 RUNNING 状态
 *  调用 shutdown() 方法之后处于 SHUTDOWN 状态,此时线程池不再接受新的任务,清除一些空闲 worker ,等待阻塞队列的任务完成
 *  调用 shutdownNow() 方法后处于 STOP 状态,此时线程池不再接受新的任务,中断所有的线程,阻塞队列中没有被执行的任务也会被全部丢弃
 *  当线程池中执行的任务为空时,也就是此时 ctl 的值为 0 时,线程池会变为 TIDYING 状态,接下来会执行 terminated() 方法
 *  执行完 terminated() 方法之后,线程池的状态就由 TIDYING 转到 TERMINATED 状态

最后上张图总结一下:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70_pic_center]

## 线程池是如何处理任务的 ##

线程池处理任务的核心方法是 execute ,大概思路就是:

*  如果 command 为 null ,没啥说的,直接抛出异常就完事儿了
 *  如果当前线程数小于 corePoolSize ,会新建一个核心线程执行任务
 *  如果当前线程数不小于 corePoolSize ,就会将任务放到队列中等待,如果任务排队成功,仍然需要检查是否应该添加线程,所以需要重新检查状态,并且在必要时回滚排队;如果线程池处于 running 状态,但是此时没有线程,就会创建线程
 *  如果没有办法给任务排队,说明这个时候,缓存队列满了,而且线程数达到了 maximumPoolSize 或者是线程池关闭了,系统没办法再响应新的请求,此时会执行拒绝策略

public void execute(Runnable command) { 
        if (command == null)
            throw new NullPointerException();
    		
        int c = ctl.get();
        // 当前线程数小于 corePoolSize 时,调用 addWorker 创建核心线程来执行任务
        if (workerCountOf(c) < corePoolSize) { 
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        // 当前线程数不小于 corePoolSize ,就将任务添加到 workQueue 中
        if (isRunning(c) && workQueue.offer(command)) { 
        	// 获取到当前线程的状态,赋值给 recheck ,是为了重新检查状态
            int recheck = ctl.get();
            // 如果 isRunning 返回 false ,那就 remove 掉这个任务,然后执行拒绝策略,也就是回滚重新排队
            if (! isRunning(recheck) && remove(command))
                reject(command);
            // 线程池处于 running 状态,但是没有线程,那就创建线程执行任务
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        // 如果放入 workQueue 失败,尝试通过创建非核心线程来执行任务
        // 如果还是失败,说明线程池已经关闭或者已经饱和,会拒绝执行该任务
        else if (!addWorker(command, false))
            reject(command);
    }

在上面源码中,判断了两次线程池的状态,为什么要这么做呢?  
这是因为在多线程环境下,线程池的状态是时刻发生变化的,可能刚获取线程池状态之后,这个状态就立刻发生了改变.如果没有二次检查的话,线程池处于非 RUNNING 状态时, command 就永远不会执行  
来张图,总结一下上面说的:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70_pic_center 1]  
这篇文章写到这里就没有啦~  
希望你能从中得到一些收获  
感谢你的阅读哇

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200612165744689.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200612180641819.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3psbF8wNDA1,size_16,color_FFFFFF,t_70#pic_center