对于ScheduledThreadPoolExecutor的几点学习

1.计时:

scheduleAtFi xedRate 从任务开始时计时,也就是下次执行时间=本次启动时间+延时

scheduleWithFixedDelay 从任务 结束开始计时,下次执行时间=本次结束时间+延时


2.关于线程池大小(转载 http://www.iteye.com/topic/1118660)

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


 

 

整个ThreadPoolExecutor的任务处理有4步操作:

  • 第一步,初始的poolSize < corePoolSize,提交的runnable任务,会直接做为new一个Thread的参数,立马执行

  • 第二步,当提交的任务数超过了corePoolSize,就进入了第二步操作。会将当前的runable提交到一个block queue中

  • 第三步,如果block queue是个有界队列,当队列满了之后就进入了第三步。如果poolSize < maximumPoolsize时,会尝试new 一个Thread的进行救急处理,立马执行对应的runnable任务

  • 第四步,如果第三步救急方案也无法处理了,就会走到第四步执行reject操作。

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

  • block queue有以下几种实现:
    1. ArrayBlockingQueue :  有界的数组队列
    2. LinkedBlockingQueue : 可支持有界/无界的队列,使用链表实现
    3. PriorityBlockingQueue : 优先队列,可以针对任务排序
    4. SynchronousQueue : 队列长度为1的队列,和Array有点区别就是:client thread提交到block queue会是一个阻塞过程,直到有一个worker thread连接上来poll task。

  • RejectExecutionHandler是针对任务无法处理时的一些自保护处理:
    1. Reject 直接抛出Reject exception
    2. Discard 直接忽略该runnable,不可取
    3. DiscardOldest 丢弃最早入队列的的任务
    4. CallsRun 直接让原先的client thread做为worker线程,进行执行

容易被人忽略的点:

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

所以建议: block size >= corePoolSize ,不然线程池就没任何意义

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

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

  *  这里的corePoolSize就是连接池的maxActive的概念,它没有minIdle的概念(每个线程可以设置keepAliveTime,超过多少时间多有任务后销毁线程,但不会固定保持一定数量的threads)。 

  * 这里的maximumPoolSize,是一种救急措施的第一层。当threadPoolExecutor的工作threads存在满负荷,并且 block queue队列也满了,这时代表接近崩溃边缘。这时允许临时起一批threads,用来处理runnable,处理完后立马退出。

所以建议:  maxi mumPoolSize >= corePoolSize =期望的最大线程数。 (我曾经配置了corePoolSize=1, maximumPoolSize =20, blockqueue为无界队列,最后就成了单线程工作的pool。典型的配置错误)

 


 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值