线程池核心参数
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
1.corePoolSize:核心线程池(线程池内部运行起来之后,最少有多少个线程等活.核心线程是懒加载)
2.maximumPoolSize:最大线程数(当工作队列堆满了,再来任务就创建非核心线程处理)
3.keepAliveTime:最大空闲时间(默认非核心线程,没活之后,只能空闲这么久,时间到了干掉)
4.unit:空闲时间单位(上面的时间单位)
5.workQueue:工作队列(当核心线程数足够后,投递的任务会扔到这个工作队列存储.LinkedBlockingQueue)
6.threadFactory:线程工厂(构建线程的,根据阿里的规范,线程一定要给予一个有意义的名字,方便后期排查错误)
7.handler:拒绝策略(核心数到了,队列拉满了,非核心数到了,再来任务走拒绝策略.....)
线程池参数如何设置
1.核心线程数:配置核心线程数,需要观察两个参数
• 硬件的CPU内核数
• 业务类型
○ CPU密集型
○ IO密集型
○ 混合型(一半CPU,一半IO)
考虑CPU密集型,其实所谓CPU密集型就是需要CPU一直调度当前线程,当前线程做的业务大多数是计算、数据转换等等,不会出现阻塞的情况.核心线程数就设置CPU内核数±1即可.但是由于CPU厂商不同,性能不同,加上服务器操作系统区别,CPU内核数±1不一定是最佳的,需要一定的压测得出一个合理的数值.jmeter压测即可.
考虑IO密集型,什么叫IO密集型呢,比如你的业务涉及到了大量的查询数据库,查询三方服务获取一些数据,而查询数据的时候,线程都基本处理阻塞状态.这种查询三方服务或者是数据库的操作,可能会因为第三服务的网络抖动,或者查询数据库没有走索引之类的,对阻塞时间有一定影响,IO密集型的方式,没有特别好用的公式.
想获取合理的数值,可以优先根据IO密集和CPU密集大致得出一个核心线程数,基于这个数值去做压测,根据测试的结果,你可以调大核心线程数,再测,调小核心线程数再测,直到得出一个效率最高的数值.
压测的过程中,需要动态修改线程池中的参数,而线程池恰恰可以做到动态修改,只需要执行set方法即可,可以自行实现.也可以用一些三方的开源框架,基于美团的动态线程池策略开源的一个线程池监控工具Hippo4j.
2.最大线程数:
其实核心线程数已经可以做到尽可能发挥CPU性能了,所以最大线程数最好设置为跟核心线程数一致.如果在核心线程的基础上,又多追加了几个线程,反而会导致性能下降~~最大线程数=核心线程数
3.工作队列:
工作队列是任务排队的地方,很多任务会扔到这个队列中排队,等待线程执行.
每个任务都是Runable的实现,是一个对象,对象要占用堆内存空间.不能让排队的任务压爆JVM内存.
任务扔到工作队列,需要等待排队处理,你可以考虑排在最后面的任务需要多久才能处理到.再根据的业务允许的延迟时间考虑,你的工作队列要多长.
4.拒绝策略:
当工作队列满了,如果最大线程数=核心线程,那就要走拒绝策略了.
如果你的任务是个日志记录之类的丢弃也无所谓可以直接丢弃.
如果你的任务是核心业务线必备的一环,那就不能丢弃,你可以让业务线程处理,你也可以把任务留存好,做最终一致性.
DiscardPolicy() //什么都不做(直接丢弃)
AbortPolicy() //抛出拒绝异常
CallerRunsPolicy() //让主线程处理
DiscardOldestPolicy() //把队列中最前面的干掉然添加(一般不用)
