对java线程池ThreadPoolExecutor的理解

╰半夏微凉° 2021-11-05 08:36 440阅读 0赞

# 应用场景 #

## 提高性能 ##

多个任务同步执行，提高性能。

## 资源隔离，熔断，快速返回 ##

Spring Cloud 里面的 Hystrix 组件，就是基于线程池来做的熔断，资源隔离。  
每个请求都对应一个线程池，可以根据任务耗时及并发情况，调整线程池大小。将不同的请求隔离开来（比如：查询，交易，会员…），这样即使某个接口出现问题，不会耗尽系统资源，导致别的接口用不了。

# 线程池=食堂吃饭排队 #

其实软件就是现实世界的抽象表示。可以对比食堂吃饭排队来理解线程池。

## 一个任务一个线程 ##

只要在食堂吃过饭的人都知道，食堂有好几个打饭的窗口。假如每次有人来吃饭开一个窗口，没人就关掉空闲的窗口，你们觉得这样合适吗？每个窗口需要一个分配一片场地，还要配备饭菜，打饭人员。可能一个人过来打个饭1分钟搞定。然后准备这个窗口却需要1个月。要是吃饭的人多了。现实世界不可能存在那么大的空间和资源来创建打饭窗口。

对比软件世界就是：**来一个任务创建一个线程。线程创建和打饭窗口创建一样需要大量的资源：，系统调用，内核态到用户态切换，分配，初始化线程堆栈等。每次任务执行都得等待线程创建。要是任务多，也会耗尽系统资源。**

## 灵活调整窗口数量 ##

大家都知道原来21楼食堂只有一个窗口，然后窗口的服务能力有限，我们公司人又多，还有其他公司的人也过来吃，结果导致有相当一部分同学吃不上饭，或者等很久才吃到。大家说这样是不是很不合理。好在后面食堂又增加了两个窗口，现在一共有3个窗口了。经过多次体验之后发现确实速度快很多。基本都能吃上饭了（虽然经常找不到座位，看样子座位也得增加了…）。

对比软件世界就是：**任务过多，多开几个线程处理。**

食堂比较聪明，他们发现中午吃饭的人比较多。晚上吃饭的人少。于是他们在晚上的时候就只开一个窗口，节约点员工开支，已经摆放菜品等工作。

对比软件世界就是：**设置核心线程和最大线程数，当排队人数排满等待队列后就会创建新的线程来处理，不会超过最大线程数 。**

## 不限制排队队列长度 ##

好，那么现在我们先创建好了几个打饭窗口，没有限制排队人数。结果导致排队了几千上万人。然后我们的打饭窗口速度有限，只能提供100人份饭菜。难不成后面排队的就一直在那干等？等到海枯石烂，饿死为止，又或者吵架闹事，拆食堂，导致一个人都吃不了饭？要是食堂能限制排队人数100为止，那该多好。至少后面来的人可以选择去别的地方吃饭，前面的人丝毫不受影响，依旧能有愉快的用餐体验。

对比软件世界就是：**ThreadPoolExecutor线程池里面的workQueue队列长度限制，不能太长，不然会导致任务堆积，处理缓慢。甚至OOM内存溢出。**

# 为什么需要线程池 #

大家应该都知道线程创建成本是很高的

*  系统调用，内核态到用户态切换
 *  分配，初始化线程堆栈等。

因此每次任务过来new一个线程并不合理。  
如果用过**阿里编程规约**扫描过代码的同学就会发现，有如下提示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1Mjg4MDIz_size_16_color_FFFFFF_t_70]  
**通过线程池就可以复用事先创建好的线程，以提高性能。**

# 如何创建线程池 #

**阿里编程规范**中有提到  
线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。  
**原因如下：**  
1)FixedThreadPool 和 SingleThreadPool: 允许的请求队列长度为 Integer.MAX\_VALUE，可能会堆积大量的请求，从而导致 OOM。2)CachedThreadPool 和 ScheduledThreadPool: 允许的创建线程数量为 Integer.MAX\_VALUE，可能会创建大量的线程，从而导致 OOM。  
![在这里插入图片描述][20190808213300920.png]  
图一：Executors 下创建 fixed thread pool  
从图一中我们可以看出，Executors.newFixedThreadPool 指定了线程的数量，但是由于使用的LinkedBlockingQueue，由于没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX\_VALUE）；如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。  
![在这里插入图片描述][20190808213307202.png]  
图二：Executors 下创建 cached thread pool  
图二中，我们可以看出，Executors.newCachedThreadPool 并没有限定线程的数量

**直接new ThreadPoolExecutor**

new ThreadPoolExecutor(corePoolSize,
                    maximumPoolSize,
                    keepAliveTime,
                    TimeUnit.SECONDS,
                    new LinkedBlockingQueue<>(maxBlockingQueue), new JlpayThreadFactory());

通过查阅源码发现如下几个很重要的参数  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1Mjg4MDIz_size_16_color_FFFFFF_t_70 1]

*  **corePoolSize** 核心线程数  
    无论什么情况都会保持的线程数
 *  **maximumPoolSize** 最大线程数  
    最大的线程数 ，  
    **当提交的任务大于corePoolSize 核心线程数 +workQueue 队列长度 后再提交的任务才会新增线程处理，不超过maximumPoolSize 最大线程数**
 *  **workQueue** 排队队列  
    **这个一定要设置队列长度，不然会导致OOM /任务处理等待时间过久**

# 如何配置合适的线程池参数 #

1.  **corePoolSize 核心线程数** 根据具体的业务情况(IO密集型，还是CPU密集型)，通过压测找到最合适的线程数。我们的情况建议30-50。如果是比较空闲的业务可以设置少一些10个左右。
2.  **maximumPoolSize 最大线程数** 考虑频繁线程切换带来的开销，不能太大了。 如果是比较稳定的并发量，建议和corePoolSize 线程数一样，这样可以避免（maximumPoolSize -corePoolSize ）个线程创建销毁的开销。
3.  **workQueue 排队队列的长度** 这个关键在于业务是否容忍响应慢的情况，排队多了，等待的时间会越长，建议在线程数的两倍以内。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1Mjg4MDIz_size_16_color_FFFFFF_t_70]: /images/20211104/e67ed4d10107411182c7605817b4a6ef.png
[20190808213300920.png]: /images/20211104/7c3f3e41b6de41268a45e5033a06127e.png
[20190808213307202.png]: /images/20211104/0d5b577d0f554b3288f49b4dde09be65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1Mjg4MDIz_size_16_color_FFFFFF_t_70 1]: /images/20211104/21084ad41a83424395841cc1b6c12e62.png