实现优先使用运行线程及调整线程数大小的线程池

当前在JDK中默认使用的线程池 ThreadPoolExecutor,在具体使用场景中,有以下几个缺点

  1. core线程一般不会timeOut
  2. 新任务提交时,如果工作线程数小于 coreSize,会自动先创建线程,即使当前工作线程已经空闲,这样会造成空闲线程浪费
  3. 设置的maxSize参数只有在队列满之后,才会生效,而默认情况下容器队列会很大(比如1000)

如一个coreSize为10,maxSize为100,队列长度为1000的线程池,在运行一段时间之后的效果会是以下2个效果:

  1. 系统空闲时,线程池中始终保持10个线程不变,有一部分线程在执行任务,另一部分线程一直wait中(即使设置allowCoreThreadTimeOut)
  2. 系统繁忙时,线程池中线程仍然为10个,但队列中有还没有执行的任务(不超过1000),存在任务堆积现象

本文将描述一下简单版本的线程池,参考于 Tomcat ThreadPoolExecutor, 实现以下3个目标

  1. 新任务提交时,如果有空闲线程,直接让空闲线程执行任务,而非创建新线程
  2. 如果coreSize满了,并且线程数没有超过maxSize,则优先创建线程,而不是放入队列
  3. 其它规则与ThreadPoolExecutor一致,如 timeOut机制
继续阅读“实现优先使用运行线程及调整线程数大小的线程池”

在基于spring体系的业务中正确地关闭线程池

在业务代码中,特别是基于spring体系的代码中,均会使用线程池进行一些操作,比如异步处理消息,定时任务,以及一些需要与当前业务分离开的操作等。常规情况下,使用spring体系的TaskExecutor或者是自己定义ExecutorService,均可以正常地完成相应的操作。不论是定义一个spring bean,或者是使用 static Thread工具类均是能满足条件。

但是,如果需要正常地关闭spring容器时,这些线程池就不一定能够按照预期地关闭了。结果就是,当使用代码 context.close() 时,期望进程会正常地退出,但实际上进程并不会退出掉.原因就在于这些线程池中还在运行的线程。
本文描述了在基于spring boot的项目中,如何正确地配置线程池,以保证线程池能够正确的在整个spring容器周期内运行,并且在容器正常关闭时能够一并退出掉.

  • 定义bean时添加destroyMethod方法或相应生命周期方法
  • 设置线程池中线程为daemon
  • 为每个线程池正确地命名及使用ThreadFactory
  • 丢弃不再需要的周期性任务
  • 监听ContextClosedEvent,触发额外操作
继续阅读“在基于spring体系的业务中正确地关闭线程池”

jdk线程池中调整coreSize无效的问题分析及处理

近期在ETL项目中,增加一个用于监控队列数和当前线程数之间的关系,并动态调节线程池大小的一个功能。其作用机制即是指当发现队列中任务太多时,能够增大线程数,以达到使用更多的线程来运行任务的目的。相应的伪代码如下所示:

    extThreadPoolExecutor.setCorePoolSize(newCorePoolSize);
    extThreadPoolExecutor.prestartCoreThread();

但是在后面通过监控发现以下的信息

队列总数:1670,核心线程数:500,活跃线程数:200

即相应的核心线程数是已经作了相应的调整,但是活跃线程数,却始终没有上升。没有达到调节线程数的目的。
从理论上说,如果增大了核心线程数,那么线程数会在新任务时,会自动创建新的线程来进行相应的任务,并且我们通过手动启动核心线程来强制运行任务,因此也不会出现线程并没有创建的问题(详细可以查看prestartCoreThread的作用)。

继续阅读“jdk线程池中调整coreSize无效的问题分析及处理”