线程池核心参数

线程池核心参数

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() //把队列中最前面的干掉然添加(一般不用)