网站首页 > 技术文章 正文
前言
在开发过程中,难免会使用到线程池来处理各种各样的场景。每次的使用,要不是copy之前的代码,要不就上网找个例子,要不就创建后,盲改一下参数,觉得差不多就行了。但我们真正用对了线程池了吗?各个参数是什么意思,分别起什么作用?我们都了解了吗?如果没有的话,咱这次就来好好聊聊 “线程池中各个参数分别有什么含义,如何设置最合理”这个话题
ThreadPoolExecutor的重要参数
我们先来看看ThreadPoolExecutor的带全参数的构造器
/**
* Creates a new {@code ThreadPoolExecutor} with the given initial
* parameters.
*
* @param corePoolSize the number of threads to keep in the pool, even
* if they are idle, unless {@code allowCoreThreadTimeOut} is set
* @param maximumPoolSize the maximum number of threads to allow in the
* pool
* @param keepAliveTime when the number of threads is greater than
* the core, this is the maximum time that excess idle threads
* will wait for new tasks before terminating.
* @param unit the time unit for the {@code keepAliveTime} argument
* @param workQueue the queue to use for holding tasks before they are
* executed. This queue will hold only the {@code Runnable}
* tasks submitted by the {@code execute} method.
* @param threadFactory the factory to use when the executor
* creates a new thread
* @param handler the handler to use when execution is blocked
* because the thread bounds and queue capacities are reached
* @throws IllegalArgumentException if one of the following holds:<br>
* {@code corePoolSize < 0}<br>
* {@code keepAliveTime < 0}<br>
* {@code maximumPoolSize <= 0}<br>
* {@code maximumPoolSize < corePoolSize}
* @throws NullPointerException if {@code workQueue}
* or {@code threadFactory} or {@code handler} is null
*/
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
- 1、corePoolSize:核心线程数
核心线程数大小,这个参数含义是在线程池创建后,不管有没有任务,这些线程数是一直存在的,除非设置了allowCoreThreadTimeout。
这好比在公司里的正编员工,这些员工比较稳定,不管公司的活是多是少,这些人都不会被辞退,都是长期存在的
- 2、maximumPoolSize:最大线程数
最大线程数,这个参数含义是线程池允许创建最大的线程数,它在什么时候创建的呢?有什么限制呢?
- 当线程数>=corePoolSize,并且workQueue队列中的任务已满时,线程池会创建新的线程来处理队列中的任务
- 当线程数=maximumPoolSize,并且workQueue队列中的任务已满时,表示线程池已无法承载更多的任务了,此时线程池会根据handler拒绝策略来拒绝任务
这好比公司里的临时工,这些员工并不稳定,当公司活多时,正式员工处理不过来,就会招募一些临时工过来消化这些任务,当这些任务消化得差不多了,这些临时工就会被裁掉,释放资源到社会。
PS:maximumPoolSize设置的值不能小于corePoolSize的值,否则会在程序运行时抛IllegalArgumentException异常
- 3、keepAliveTime:空闲线程存活时间
线程空闲存活的时间,这个参数含义是线程自上一次处理任务到现在的空闲时间。当这个空闲时间>=keepAliveTime时,线程销毁并清出线程池,直到线程池内的线程数量=corePoolSize。但如果allowCoreThreadTimeout=true时,线程会一直被销毁与清出线程池,直至线程数量为0。 - 4、unit:时间单位
时间单位,与keepAliveTime结合着用,keepAliveTime是一个数字,但没单位,而这个参数的含义为这个keepAliveTime添加上一个单位,TimeUnit有以下值:
TimeUnit.DAYS:天
TimeUnit.HOURS:小时
TimeUnit.MINUTES:分
TimeUnit.SECONDS:秒
TimeUnit.MILLISECONDS:毫秒
TimeUnit.MICROSECONDS:微妙
TimeUnit.NANOSECONDS:纳秒
- 5、workQueue:线程池任务队列
线程池任务队列,当核心线程池已经都在执行任务了,无霞应接更多的任务时,这些任务就会放到队列中等待执行。BlockingQueue<T>是一个接口,在同一个包(java.util.concurrent)下有以下的实现类
ArrayBlockingQueue:一个由数组结构组成、遵循FIFO原则的有界阻塞队列。
LinkedBlockingQueue:一个由链表结构组成的无界阻塞队列,如果大量任务堆积在这个队列中,会导致OOM。
SynchronousQueue:同步移交队列,准确说这已经不是一个队列了,它是一个不存储元素的阻塞队列,任务来至即交给工作线程处理,所以最多也只能有maximumPoolSize个任务在执行,多了就要抛异常了。
PriorityBlockingQueue:一个支持优先级排序的有界阻塞队列,任务的优先级由Comparator来决定。
DelayQueue:一个使用优先级队列实现的无界阻塞队列,只有在延迟期满时才能从中提取元素。
LinkedTransferQueue:一个由链表结构组成的无界阻塞队列。与SynchronousQueue类似,还含有非阻塞方法。
LinkedBlockingDeque:一个由链表结构组成的双向阻塞队列。
PS:Executors.newFixedThreadPool 采用就是 LinkedBlockingQueue
- 6、threadFactory:创建线程的工厂
创建线程的工厂,这个参数的含义是线程池在创建新的线程时,会使用哪个线程工厂来完成创建,可以通过此方法来设置线程的一些基本属性,如优先级,线程名称,线程类型等。ThreadFactory是一个接口,这里可以传入一个ThreadFactory的子类。 - 7、handler:拒绝策略
拒绝策略,这个参数的含义为:当前线程数=maximumPoolSize 并且队列里面放满了任务时,如果程序继续向线程池提交的任务,此时线程池应该执行怎么样的拒绝策略。RejectedExecutionHandler是一个接口,在同一个包(java.util.concurrent),有以下4种实现方法:
AbortPolicy:拒绝并抛出异常。
CallerRunsPolicy:使用当前调用的线程来执行此任务。
DiscardOldestPolicy:抛弃队列头部(最旧)的一个任务,并执行当前任务。
DiscardPolicy:忽略并抛弃当前任务
PS:线程池的默认策略是 AbortPolicy 拒绝并抛出异常
如何设置最合理
参数的含义介绍完了,但怎么设置这些参数才是最合理的呢?这些参数设置后,是不是适用业务的所有场景呢?下次创建是不是只需要复制就可以呢?是不是很多疑问?没关系,我们一步步分析下去。
我们知道线程池中的两个非常重要的参数:corePoolSize、maximumPoolSize,直接影响执行的性能和提交到线程池的任务能否执行完成。
首先我们对线程池负责执行的任务分为三种情况:
- CPU密集型任务,比如找出1-1000000中的素数
- IO密集型任务,比如文件IO、网络IO
CPU密集型
CPU密集型任务的特点时,线程在执行任务时会一直利用CPU,所以对于这种情况,就尽可能避免发生线程上下文切换。
比如,现在我的电脑只有一个CPU,如果有两个线程在同时执行找素数的任务,那么这个CPU就需要额外的进行线程上下文切换,从而达到线程并行的效果,此时执行这两个任务的总时间为:
任务执行时间*2+线程上下文切换的时间
而如果只有一个线程,这个线程来执行两个任务,那么时间为:
任务执行时间*2
所以对于CPU密集型任务,线程数最好就等于CPU核心数,可以通过以下API拿到你电脑的核心数:
Runtime.getRuntime().availableProcessors()
只不过,为了应对线程执行过程发生缺页中断或其他异常导致线程阻塞的请求,我们可以额外在多设置一个线程,这样当某个线程暂时不需要CPU时,可以有替补线程来继续利用CPU。
所以,对于CPU密集型任务,我们可以设置线程数为:CPU核心数+1
IO密集型
我们在来看IO型任务,线程在执行IO型任务时,可能大部分时间都阻塞在IO上,假如现在有10个CPU,如果我们只设置了10个线程来执行IO型任务,那么很有可能这10个线程都阻塞在了IO上,这样这10个CPU就都没活干了,所以,对于IO型任务,我们通常会设置线程数为:2*CPU核心数
不过,就算是设置为了2*CPU核心数,也不一定是最佳的,比如,有10个CPU,线程数为20,那么也有可能这20个线程同时阻塞在了IO上,所以可以再增加线程,从而去压榨CPU的利用率。
通常,如果IO型任务执行的时间越长,那么同时阻塞在IO上的线程就可能越多,我们就可以设置更多的线程,但是,线程肯定不是越多越好,我们可以通过以下这个公式来进行计算:
线程数 = CPU核心数 *( 1 + 线程等待时间 / 线程运行总时间 )
- 线程等待时间:指的就是线程没有使用CPU的时间,比如阻塞在了IO
- 线程运行总时间:指的是线程执行完某个任务的总时间
按上述公式,如果我们执行的任务IO密集型任务,那么:线程等待时间 = 线程运行总时间,所以:
线程数 = CPU核心数 *( 1 + 线程等待时间 / 线程运行总时间 )
= CPU核心数 *( 1 + 1 )
= CPU核心数 * 2
以上只是理论,实际工作中情况会更复杂,比如一个应用中,可能有多个线程池,除开线程池中的线程可能还有很多其他线程,或者除开这个应用还是一些其他应用也在运行,所以实际工作中如果要确定线程数,最好是压测。
总结
- CPU密集型任务:CPU核心数+1,这样既能充分利用CPU,也不至于有太多的上下文切换成本
- IO型任务:建议压测,或者先用公式计算出一个理论值(理论值通常都比较小)
- 对于核心业务(访问频率高),可以把核心线程数设置为我们压测出来的结果,最大线程数可以等于核心线程数,或者大一点点,比如我们压测时可能会发现500个线程最佳,但是600个线程时也还行,此时600就可以为最大线程数
- 对于非核心业务(访问频率不高),核心线程数可以比较小,避免操作系统去维护不必要的线程,最大线程数可以设置为我们计算或压测出来的结果。
猜你喜欢
- 2024-10-22 线程池调优之动态参数配置 动态设置线程池大小
- 2024-10-22 java线程池参数及使用 java线程池的用法
- 2024-10-22 面试官:说说你对线程池的了解 线程池实现原理面试
- 2024-10-22 「每日分享」高阶程序员需要掌握的常见性能优化策略
- 2024-10-22 池化技术学习 池化方法
- 2024-10-22 「Java基础」「多线程」-线程池 java多个线程池
- 2024-10-22 线程池配置的常见误区 线程池配置参数有哪些
- 2024-10-22 创建线程池参数有哪些作用? 创建线程池的7个参数
- 2024-10-22 一文搞懂!多线程之间的通信及线程池
- 2024-10-22 码农大叔带你——解析线程池 线程池的主要处理流程
你 发表评论:
欢迎- 最近发表
-
- 吴谨言专访大反转!痛批耍大牌后竟翻红,六公主七连发力显真诚
- 港股2月28日物业股涨幅榜:CHINAOVSPPT涨1.72%位居首位
- 港股2月28日物业股午盘:CHINAOVSPPT涨1.72%位居首位
- 港股3月2日物业股涨幅榜:CHINAOVSPPT涨1.03%位居首位
- 港股3月2日物业股午盘:CHINAOVSPPT涨1.03%
- 天赋与心痛的背后:邓鸣贺成长悲剧引发的深刻反思
- 冯小刚女儿徐朵追星范丞丞 同框合照曝光惹人羡,回应网友尽显亲民
- “资本大佬”王冉:51岁娶小17岁童瑶,并承诺余生为娇妻保驾护航
- 港股3月2日物业股午盘:CHINAOVSPPT涨1.03%位居首位
- 「IT之家开箱」vivo S15 图赏:双镜云窗,盛夏风光
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)