乐趣区

关于java:开源项目可观测易使用的SpringBoot线程池

jiezi

在开发 spring boot 应用服务的时候，难免会应用到异步工作及线程池。spring boot 的线程池是能够自定义的，所以咱们常常会在我的项目外面看到相似于上面这样的代码

@Bean
public Executor taskExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(config.getCorePoolSize());
    executor.setMaxPoolSize(config.getMaxPoolSize());
    executor.setQueueCapacity(config.getQueueCapacity());
    executor.setThreadNamePrefix("TaskExecutePool-");
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.setWaitForTasksToCompleteOnShutdown(true);
    executor.initialize();
    return executor;
}

应用起来很不便，然而这样做有几个问题：

  • 开发人员在代码外面随便定义线程池，开发人员 A 自定义一个线程池，开发人员 B 自定义一个线程池。线程池的资源的应用没有布局与正当的安顿，前期保护的老本升高。
  • 一旦发现线程池数量有余或资源满载，很难调整配置，只能调整代码，重新部署。
  • 多人编写代码，很难统计那个服务外面存在线程池，有几个线程池。
  • 如果不去跟踪代码，你很难晓得它的应用状况。定义了 50 个线程，存不存在资源节约？存不存在资源期待？

为了解决上述的问题，我开发了一个 Spring Boot Starter（开源我的项目地址：https://gitee.com/hanxt/zimug…），不便集成到 Spring Boot 我的项目外面去。指标是：在不扭转 SpringBoot 线程池的外围实现的根底上，使其可视化、易观测、易配置、易使用。

须要阐明的是：zimug-monitor-threadpool 并未扭转 SpringBoot 线程池的实现，只是在其根底上增加了初始化阶段的配置自动化加载，运行时的状态监控。所以任何无关 Spring Boot 线程池运行时性能的探讨，都与本文及其实现无关。

一、易集成、易配置

通过上文的我的项目地址获取源码，而后 maven 编译 install 本地 m2 仓库。而后通过上面的 maven 坐标引入

<dependency>
    <groupId>com.zimug</groupId>
    <artifactId>zimug-monitor-threadpool</artifactId>
    <version>1.0</version>
</dependency>

如下配置 spring boot YAML(application.yml)所示，配置了两个线程池，别离是 test、test2。当 thread-pool.enable=true 的时候线程池配置失效。

thread-pool:
  enable: true
  poolLists:
    - poolId: test    #线程池惟一标识
      poolName: 测试 1   #线程池的中文形容，比方线程池给谁用？coreSize: 5  #线程池初始化外围线程数量
      maxSize: 10  #线程池最大线程容量
      queueCapacity: 10  #线程池期待队列的容量
    - poolId: test2
      poolName: 测试 2
      coreSize: 5
      maxSize: 10
      queueCapacity: 10

通过上面的这张图了解下面的配置信息

  • 当线程工作数量 core_size 被沉闷工作线程占满之后，线程工作会被放入期待队列(queueCapacity=10)
  • 当期待队列 queueCapacity 也被占满之后，才会扩充线程池的容量
  • 线程池的容量最大扩大到 maxSize。如果 maxSize 和 queueCapacity 都满了，工作就阻塞了。

二、易使用

应用形式和 SpringBoot 代码形式自定义线程池的应用形式是一样的。应用 @Async 注解的值是 test，调用该注解标识的函数就会放入上文中配置的 test 线程池外面去执行。

@Component
public class TestTask {@Async("test")   // 留神这里，test 是线程池配置的 poolId
    public Future<String> test() throws Exception {System.out.println("以后线程：" + Thread.currentThread().getName());
        return new AsyncResult<>("测试工作");
    }
}

三、可视化易观测

在我的项目中引入 zimug-monitor-threadpool 之后，进行线程池配置，应用线程池。拜访服务的 /pool.html 即可获取以后 SpringBoot 服务的线程池配置信息，以及运行时状态信息。

  • 线程池 ID、形容、初始化线程数、最大线程数、工作期待队列的容量是上文中 yaml 动态配置
  • 以后线程池的容量，即：线程池以后的线程数量（沉闷 + 非沉闷线程数总和）
  • 以后沉闷线程数，即：正在运行程序工作的线程数量
  • 线程池沉闷线程的最大峰值，如果该值等于初始化线程数，阐明已经呈现了工作期待，即：工作放入期待队列，效率较低。如果该值大于初始化线程数，阐明工作期待队列已经满载，须要扩容。如果该值靠近等于最大线程数，就须要扩充最大线程数的值。
  • 当前任务期待队列残余的容量，剩的越少，阐明正在期待执行的工作就越多。

四、实现原理

zimug-monitor-threadpool 的实现原理也非常简单，简略说一下原理，具体实现参考源码。

  • 首先通过 SpringBoot 加载 yaml 配置信息，配置加载实现之后自定义实现配置自动化加载。这个实现原理及实现办法网上到处都是，我就不写了。

  • 将配置信息加载之后 new 一个 ThreadPoolTaskExecutor 对象，并通过 Spring 的 ConfigurableBeanFactory 将线程池对象的 bean 注册到 Spring 上下文环境中，bean 的 id 是 poolId 配置。就能够提供给运行时工作应用了。

    configurableBeanFactory.registerSingleton(pool.getPoolId(), taskExecutor);

  • 待须要监测线程池运行时状态的时候，再把线程池对象通过 getBean 办法获取到，从而获取运行时信息返回给前台申请。

    ThreadPoolTaskExecutor memThreadPool = (ThreadPoolTaskExecutor) applicationContext.getBean(poolModel.getPoolId());

欢送关注我的布告号：字母哥杂谈，回复 003 赠送本文所在专栏《docker 修炼之道》的 PDF 版本，30 余篇精品 docker 文章。字母哥博客：zimug.com

退出移动版