ThreadPoolExecutor几点使用建议

  • 时间:
  • 浏览:6
  • 来源:万人红黑大战棋牌_万人红黑大战棋牌官网

再提供有一一个 btrace脚本,分析线上的thread pool容量规划是与非 合理,可不可不可以运行时输出poolSize等因此 数据。

  *  据dbcp pool为例,会有minIdle , maxActive配置。minIdle代表是常驻内存中的threads数量,maxActive代表是工作的最大程序数。

几点说明:(相信你这名网上一搜一大把,我这里简单介绍下,为上端做一下铺垫)

2.  corePoolSize 和 maximumPoolSize的区别, 和因此 人儿正常理解的数据库连接池不太一样。

好多好多 有建议: block size >= corePoolSize ,不然程序池就没任何意义

  *  这里的corePoolSize因此连接池的maxActive的概念,它这么minIdle的概念(每个程序可不可不可以设置keepAliveTime,超很哪几个时间多有任务后销毁程序,默认只会针对maximumPoolSize参数的程序生效,可不可不可以设置allowCoreThreadTimeOut=true,就可不可不可以对corePoolSize进行idle回收)。 

  * 这里的maximumPoolSize,是一种救急辦法 的第一层。当threadPoolExecutor的工作threads居于满负荷,因此block queue队列也满了,这时代表接近崩溃边缘。这时允许临时起一批threads,用来补救runnable,补救之前 通过keepAliveTime进行调度回收。

好多好多 有建议:  maximumPoolSize >= corePoolSize =期望的最大程序数。 (我之前 配置了corePoolSize=1, maximumPoolSize=20, blockqueue为无界队列,最后就成了单程序工作的pool。典型的配置错误)

好多好多 有建议:  RejectExecutionHandler = CallsRun ,  blockqueue size = 2 * poolSize (为啥是2倍poolSize,主要有一一个 考虑因此瞬间高峰补救,允许有一一个 thread等待有一一个 runnable任务)

因此 人儿无缘无故会在线上使用因此 程序池做异步补救,比如我前面做的

1. poolSize 代表为当前的程序数

  这是我对ThreadPoolExecutor使用过程中的因此 经验总结,希望能对因此 人儿有所帮助,如有描述不对的地方欢迎拍砖。

整个ThreadPoolExecutor的任务补救有4步操作:

容易被人忽略的点:

运行结果:

说明:

2. largestPoolSize 代表为历史最大的程序数

4. reject count 代表在800ms内的被reject的数量

将之前 串行的请求都变为了并行操作,但这么来越多的并行会增加系统的负载(比如软中断,上下文切换)。好多好多 有肯定还要对程序池做有一一个 size限制。因此为了引入异步操作后,补救因在block queue的等待过长,好多好多 有还要在队列满的时,执行有一一个 callsRun的策略,并行的操作又转为有一一个 串行补救,之前 就可不可不可以保证尽量少的延迟影响。

3. 善用blockqueue和reject组合. 这里要重点推荐下CallsRun的Rejected Handler,从字面意思因此让调用者另一方来运行。

前段时间有一一个 项目中可能性涉及少许的程序开发,把jdk cocurrent的代码重新再过了一遍。这篇文章中主因此记录一下学习ThreadPoolExecutor过程中容易被人忽略的点,Doug Lea的整个类设计还是非常nice的

3. queueSize 代表blockqueue的当前堆积的size

先看一副图,描述了ThreadPoolExecutor的工作机制: 

1.  pool threads启动后,之前 的任务获取后会通过block queue中,获取堆积的runnable task.