探秘SpringBoot默认线程池：了解其运行原理与工作方式（@Async和ThreadPoolTaskExecutor）

文章目录

  • 文章导图
  • Spring封装的几种线程池
  • SpringBoot默认线程池
    • TaskExecutionAutoConfiguration（SpringBoot 2.1后）
      • 主要作用
      • 优势
      • 使用场景
      • 如果没有它
    • 2.1版本以后
      • 如何查看参数
      • 方式一：通过@Async注解--采用ThreadPoolTaskExecutor
        • determineAsyncExecutor-查找决定使用哪个线程池
        • 实操
        • @Async注意点
      • 方式二：直接注入 ThreadPoolTaskExecutor
    • 2.1版本以前
      • 方式一：通过@Async注解--采用SimpleAsyncTaskExecutor
      • 方式二：直接注入 ThreadPoolTaskExecutor
        • 直接注入报错
        • 解决：自定义一个线程池
    • 默认的线程池好用吗？
      • TaskExecutionAutoConfiguration？
      • SimpleAsyncTaskExecutor
      • 线程池核心线程数和最大线程数设置指南
        • 线程池参数介绍
        • 线程数设置考虑因素
        • CPU密集型任务的线程数设置
        • IO密集型任务的线程数设置
        • 实际应用中的线程数计算
        • 生产环境中的线程数设置
        • 线程池参数设置建议
        • 注意事项

线程池系列文章可参考下表，目前已更新3篇，还剩1篇TODO…

线程池系列：文章
Java基础线程池TODO…
CompletableFuture线程池从用法到源码再到应用场景：全方位了解CompletableFuture及其线程池
SpringBoot默认线程池（@Async和ThreadPoolTaskExecutor）探秘SpringBoot默认线程池：了解其运行原理与工作方式（@Async和ThreadPoolTaskExecutor）
SpringBoot默认线程池和内置Tomcat线程池你是否傻傻分不清SpringBoot默认线程池和内置Tomcat线程池？

文章导图

image-20240522213822974

Spring封装的几种线程池

Spring框架为了简化并发任务的处理，提供了几种线程池的封装实现，这些线程池可以直接在Spring应用程序中使用。以下是Spring中常见的几种线程池：

线程池类型描述特点
SimpleAsyncTaskExecutor非阻塞的线程池，为每个任务创建新线程，不限制线程数量。不重用线程，适合任务量不大的情况。
SyncTaskExecutor同步执行器，任务在调用线程中直接执行，不创建新线程。无异步处理能力，适用于简单同步操作。
ConcurrentTaskExecutor包装类，允许任何实现了java.util.concurrent.Executor的实现作为Spring的TaskExecutor。提供了对现有Executor实现的适配。
ThreadPoolTaskExecutor功能丰富的线程池实现，允许配置核心线程数、最大线程数、队列容量等。适合需要精细控制线程池参数的场合。
WorkManagerTaskExecutor适用于Java EE环境下的CommonJ规范在WebLogic和WebSphere等应用服务器上有CommonJ 的 WorkManager支持时使用
TaskExecutorAdapter适配器，允许将实现了java.util.concurrent.ExecutorService的对象转换为Spring的TaskExecutor。为现有的ExecutorService提供Spring的TaskExecutor接口适配。

接下来我们重点看ThreadPoolTaskExecutor和SimpleAsyncTaskExecutor(@Async)

SpringBoot默认线程池

SpringBoot默认的线程池就是ThreadPoolTaskExecutor，但是在SpringBoot不同版本是有区别的，下面先从这个关键的TaskExecutionAutoConfiguration说起

TaskExecutionAutoConfiguration（SpringBoot 2.1后）

/*** EnableAutoConfiguration Auto-configuration for TaskExecutor.** @author Stephane Nicoll* @author Camille Vienot* @since 2.1.0*/// 仅在类 ThreadPoolTaskExecutor 存在于 classpath 时才应用
@ConditionalOnClass(ThreadPoolTaskExecutor.class)
@Configuration
// 确保前缀为 spring.task.execution 的属性配置项被加载到 bean TaskExecutionProperties 中
@EnableConfigurationProperties(TaskExecutionProperties.class)
public class TaskExecutionAutoConfiguration {/*** Bean name of the application TaskExecutor.*/public static final String APPLICATION_TASK_EXECUTOR_BEAN_NAME = "applicationTaskExecutor";private final TaskExecutionProperties properties;private final ObjectProvider<TaskExecutorCustomizer> taskExecutorCustomizers;private final ObjectProvider<TaskDecorator> taskDecorator;public TaskExecutionAutoConfiguration(TaskExecutionProperties properties,ObjectProvider<TaskExecutorCustomizer> taskExecutorCustomizers,ObjectProvider<TaskDecorator> taskDecorator) {this.properties = properties;this.taskExecutorCustomizers = taskExecutorCustomizers;this.taskDecorator = taskDecorator;}// 定义 bean TaskExecutorBuilder taskExecutorBuilder// 这是一个 TaskExecutor 构建器@Bean// 仅在该 bean 尚未被定义时才定义@ConditionalOnMissingBeanpublic TaskExecutorBuilder taskExecutorBuilder() {TaskExecutionProperties.Pool pool = this.properties.getPool();TaskExecutorBuilder builder = new TaskExecutorBuilder();builder = builder.queueCapacity(pool.getQueueCapacity());builder = builder.corePoolSize(pool.getCoreSize());builder = builder.maxPoolSize(pool.getMaxSize());builder = builder.allowCoreThreadTimeOut(pool.isAllowCoreThreadTimeout());builder = builder.keepAlive(pool.getKeepAlive());builder = builder.threadNamePrefix(this.properties.getThreadNamePrefix());builder = builder.customizers(this.taskExecutorCustomizers);builder = builder.taskDecorator(this.taskDecorator.getIfUnique());return builder;}// 懒惰模式定义 bean ThreadPoolTaskExecutor applicationTaskExecutor，// 基于容器中存在的  TaskExecutorBuilder@Lazy// 使用bean名称 : taskExecutor, applicationTaskExecutor@Bean(name = { APPLICATION_TASK_EXECUTOR_BEAN_NAME,AsyncAnnotationBeanPostProcessor.DEFAULT_TASK_EXECUTOR_BEAN_NAME })// 仅在容器中不存在类型为 Executor 的 bean 时才定义            @ConditionalOnMissingBean(Executor.class)public ThreadPoolTaskExecutor applicationTaskExecutor(TaskExecutorBuilder builder) {return builder.build();}}

注意上面的源码注释，我们可以看到@since 2.1.0，所以TaskExecutionAutoConfiguration是SpringBoot2.1以后才有的，那么这个类有啥作用呢？

TaskExecutionAutoConfiguration 是 Spring Boot 提供的一个自动配置类，它的目的是简化 Spring 应用中异步任务执行和任务调度的配置。

主要作用

  1. 自动配置异步任务执行器（Executor）： TaskExecutionAutoConfiguration 会为应用配置一个默认的 ThreadPoolTaskExecutor，这是一个基于线程池的 TaskExecutor 实现。它适用于应用中通过 @Async 注解标注的异步方法的执行。如果你不提供自定义配置，Spring Boot 将会使用这个自动配置的执行器来执行异步任务。
  2. 自动配置任务调度器（Scheduler）： 同样地，它也为应用配置一个默认的 ThreadPoolTaskScheduler，这是用于任务调度的组件，支持 @Scheduled 注解标注的方法。这个调度器允许你在应用中简便地安排定期执行的任务。
  3. 可通过应用配置文件来定制配置： TaskExecutionAutoConfiguration 支持通过 application.properties 或 application.yml 配置文件来自定义任务执行和调度的相关参数，例如线程池大小、队列容量等。这些参数分别位于 spring.task.execution 和 spring.task.scheduling 命名空间下。

优势

  • 简化配置：无需手动定义 Executor 或 Scheduler 的Bean，大大减少了样板代码。
  • 易于定制：通过配置文件即可调整线程池参数，而无需修改代码。
  • 与 Spring 生态系统的集成：自动配置的执行器和调度器与 Spring 的 @Async 和 @Scheduled 注解无缝集成。

使用场景

当你的应用需要执行异步任务或者按计划执行某些作业时，你通常会需要配置一个任务执行器或者任务调度器。在 Spring Boot 应用中，TaskExecutionAutoConfiguration 让这一步骤变得极为简单和自动化。

如果没有它

如果没有 TaskExecutionAutoConfiguration，你需要手动配置线程池、异步执行器(TaskExecutor)和任务调度器(TaskScheduler)。即，你需要在你的 Spring 配置中显式地定义相关的Bean，并可能还要为这些Bean提供自定义的配置。

总结起来，TaskExecutionAutoConfiguration 通过自动配置和简化配置工作，大大提高了开发效率，允许开发者更加专注于业务逻辑编写，而无需担心底层线程池和执行器的配置。

2.1版本以后

2.1版本后有TaskExecutionAutoConfiguration自动配置类，会帮我们自动配置默认线程池ThreadPoolTaskExecutor

线程池默认参数如下：

  • 核心线程数 (corePoolSize): 8

  • 最大线程数 (maxPoolSize): Integer.MAX_VALUE (无限制)

  • 队列容量 (queueCapacity): Integer.MAX_VALUE (无限制)

  • 空闲线程保留时间 (keepAliveSeconds): 60秒

  • 线程池拒绝策略 (RejectedExecutionHandler): AbortPolicy（默认策略，超出线程池容量和队列容量时抛出RejectedExecutionException异常）

这些参数可以通过在application.properties或application.yml文件中设置来进行自定义调整。例如：

# 核心线程数，默认为8
spring.task.execution.pool.core-size
# 最大线程数，默认为Integer.MAX_VALUE
spring.task.execution.pool.max-size
# 任务等待队列容量，默认为Integer.MAX_VALUE
spring.task.execution.pool.queue-capacity
# 空闲线程等待时间，默认为60s。如果超过这个时间没有任务调度，则线程会被回收
spring.task.execution.pool.keep-alive
# 是否允许回收空闲的线程，默认为true
spring.task.execution.pool.allow-core-thread-timeout
# 线程名前缀
spring.task.execution.thread-name-prefix=task-

如何查看参数

在 Spring Boot 中，默认的线程池由 TaskExecutorBuilder 类负责创建，它通常使用 ThreadPoolTaskExecutor 来配置默认的线程池。虽然默认的线程池参数可以根据不同的 Spring Boot 版本或特定配置而有所不同，但通常情况下，Spring Boot 默认的线程池参数如下：

在org.springframework.boot.autoconfigure.task包的TaskExecutionAutoConfiguration.java是SpringBoot默认的任务执行自动配置类。
从@EnableConfigurationProperties(TaskExecutionProperties.class)可以知道开启了属性绑定到TaskExecutionProperties.java的实体类上
img
打个断点可以看到默认参数如下：
在这里插入图片描述

进入到TaskExecutionProperties.java类中，看到属性绑定以spring.task.execution为前缀。默认线程池的核心线程数coreSize=8，最大线程数maxSize = Integer.MAX_VALUE，以及任务等待队列queueCapacity = Integer.MAX_VALUE
因为Integer.MAX_VALUE的值为2147483647(2的31次方-1)，所以默认情况下，一般任务队列就可能把内存给堆满了。我们真正使用的时候，还需要对异步任务的执行线程池做一些基础配置，以防止出现内存溢出导致服务不可用的问题。

img

方式一：通过@Async注解–采用ThreadPoolTaskExecutor

determineAsyncExecutor-查找决定使用哪个线程池

我们的@Async会默认使用什么线程池呢？这里就涉及源码了，核心源码如下：org.springframework.aop.interceptor.AsyncExecutionAspectSupport#determineAsyncExecutor

这段方法的核心作用是，根据@Async注解和方法上是否有指定的限定符来决定一个方法应该使用哪个AsyncTaskExecutor来执行异步任务。

  • 方法首先尝试从一个缓存(this.executors)中查找并返回已经与方法关联的执行器。

  • 如果缓存里没有，那么这个方法会尝试根据方法上的@Async注解中指定的限定符，从Spring应用程序上下文中查找对应的执行器。（比如@Async("taskExecutor")就会去找程序中已有的定义好的name="taskExecutor"的Bean）

  • 如果没有指定限定符或找不到对应的Bean，它将尝试使用或创建一个默认的执行器。

    • 如果是SpringBoot2.1以后，就会创建TaskExecutionAutoConfiguration帮我们自动配置好的默认线程池ThreadPoolTaskExecutor
    • 如果是SpringBoot2.1之前，TaskExecutionAutoConfiguration没有帮我们配置默认线程池，最终会找到org.springframework.core.task.SimpleAsyncTaskExecutor

  • 创建或确定执行器后，方法会将其存进缓存中，以备下次执行同一方法时使用。

protected AsyncTaskExecutor determineAsyncExecutor(Method method) {// 尝试从缓存中获取已确定的执行器AsyncTaskExecutor executor = this.executors.get(method);if (executor == null) {Executor targetExecutor; // 声明一个目标执行器String qualifier = getExecutorQualifier(method); // 获取方法上的@Async注解中指定的执行器的限定名// 如果注解中有限定名则尝试根据该名字从BeanFactory中查找对应的执行器if (StringUtils.hasLength(qualifier)) {targetExecutor = findQualifiedExecutor(this.beanFactory, qualifier);}else {// 如果未指定限定名，则使用默认的执行器targetExecutor = this.defaultExecutor;// 如果默认执行器为空，则尝试从BeanFactory中获取默认的执行器if (targetExecutor == null) {synchronized (this.executors) {// 双重检查锁定，确保只有一个线程可以初始化defaultExecutorif (this.defaultExecutor == null) {this.defaultExecutor = getDefaultExecutor(this.beanFactory);}targetExecutor = this.defaultExecutor;}}}// 如果没有合适的目标执行器，返回nullif (targetExecutor == null) {return null;}// 如果目标执行器是AsyncListenableTaskExecutor则直接使用，否则使用适配器封装以确保它实现了AsyncListenableTaskExecutor//所以SpringBoot2.1之前最终会找到org.springframework.core.task.SimpleAsyncTaskExecutorexecutor = (targetExecutor instanceof AsyncListenableTaskExecutor ?(AsyncListenableTaskExecutor) targetExecutor : new TaskExecutorAdapter(targetExecutor));// 将确定的执行器放入缓存，以便下次直接使用this.executors.put(method, executor);}// 返回确定的AsyncTaskExecutorreturn executor;
}

这个方法首先查找类型为 TaskExecutor 的Bean，如果有多个此类型的Bean，然后尝试查找名称为 “taskExecutor” 的Bean。如果这两种方式都没找到，那么将返回 null，表示没有找到适当的Bean来执行异步任务。这种情况下，AsyncExecutionInterceptor 将不会有执行器来处理异步方法。

// 会去 Spring 的容器中找有没有 TaskExecutor 或名称为 'taskExecutor' 为 Executor 的 @Nullableprotected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {if (beanFactory != null) {try {return beanFactory.getBean(TaskExecutor.class);} catch (NoUniqueBeanDefinitionException ex) {return beanFactory.getBean("taskExecutor", Executor.class);} catch (NoSuchBeanDefinitionException ex) {return beanFactory.getBean("taskExecutor", Executor.class);}}return null;}
实操
@Service
public class SyncService {@Asyncpublic void testAsync1() {System.out.println(Thread.currentThread().getName());ThreadUtil.sleep(10, TimeUnit.DAYS);}@Asyncpublic void testAsync2() {System.out.println(Thread.currentThread().getName());ThreadUtil.sleep(10, TimeUnit.DAYS);}
}

注意需要在启动类上需要添加@EnableAsync注解，否则不会生效。

@RestController
public class TestController {@AutowiredSyncService syncService;@SneakyThrows@RequestMapping("/testSync")public void testTomcatThreadPool() {syncService.testAsync1();syncService.testAsync2();}
}

请求后观察控制台输出结果，打印线程名如下，说明我们这里采用的是TaskExecutionAutoConfiguration帮我们配置的默认线程池ThreadPoolTaskExecutor，就是以task-开头的

task-2
task-1
@Async注意点

  • 启动类上需要添加@EnableAsync注解

  • 注解的方法必须是public方法。

  • 注解的方法不要定义为static

  • 方法一定要从另一个类中调用，也就是从类的外部调用，类的内部调用是无效的。

Spring 基于AOP 实现了异步，因此，需要获取到容器中的代理对象才能具有异步功能。假定原对象叫obj，容器中的代理对象叫做 objproxy，在执行 fun() 会同时执行aop带来的其他方法。但是如果在fun() 中调用了 fun2()，那 fun2() 是原始的方法，而不是经过aop代理后的方法，就不会具有异步的功能。

方式二：直接注入 ThreadPoolTaskExecutor

2.1版本以后我们有TaskExecutionAutoConfiguration自动配置类，它会去配置默认的线程池，此时注入的ThreadPoolTaskExecutor就是默认的线程池

@RestController
public class TestController {@ResourceThreadPoolTaskExecutor taskExecutor; //SpringBoot2.1之前直接注入会报错@SneakyThrows@RequestMapping("/testSync")public void testTomcatThreadPool() {ThreadPoolExecutor threadPoolExecutor = taskExecutor.getThreadPoolExecutor();}
}

通过debug可以看到默认的线程池参数如下，就是我们上面介绍的

image-20240521200925922

2.1版本以前

方式一：通过@Async注解–采用SimpleAsyncTaskExecutor

最主要的就是此时我们没有TaskExecutionAutoConfiguration自动配置类，也就不会去配置默认的线程池，根据上面分析的determineAsyncExecutor方法，此时@Async会去采用默认的SimpleAsyncTaskExecutor

@Service
public class SyncService {@Asyncpublic void testAsync1() {System.out.println(Thread.currentThread().getName());ThreadUtil.sleep(10, TimeUnit.DAYS);}@Asyncpublic void testAsync2() {System.out.println(Thread.currentThread().getName());ThreadUtil.sleep(10, TimeUnit.DAYS);}
}

注意需要再启动类上需要添加@EnableAsync注解，否则不会生效。

@RestController
public class TestController {@AutowiredSyncService syncService;@SneakyThrows@RequestMapping("/testSync")public void testTomcatThreadPool() {syncService.testAsync1();syncService.testAsync2();}
}

验证输出结果，确实是采用了SimpleAsyncTaskExecutor线程池：

SimpleAsyncTaskExecutor-1
SimpleAsyncTaskExecutor-2

方式二：直接注入 ThreadPoolTaskExecutor

最主要的就是此时我们没有TaskExecutionAutoConfiguration自动配置类，也就不会去配置默认的线程池，此时直接注入就会报错，所以需要自己定义！

直接注入报错
@RestController
public class TestController {@ResourceThreadPoolTaskExecutor taskExecutor; //SpringBoot2.1之前直接注入会报错@SneakyThrows@RequestMapping("/testSync")public void testTomcatThreadPool() {ThreadPoolExecutor threadPoolExecutor = taskExecutor.getThreadPoolExecutor();}
}

此时发现在工程启动的时候就报错！

image-20240519225424332

解决：自定义一个线程池
@Configuration
public class ThreadPoolConfiguration {@Bean("taskExecutor")public ThreadPoolTaskExecutor taskExecutor() {ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();//设置线程池参数信息taskExecutor.setCorePoolSize(10);taskExecutor.setMaxPoolSize(50);taskExecutor.setQueueCapacity(200);taskExecutor.setKeepAliveSeconds(60);taskExecutor.setThreadNamePrefix("myExecutor--");taskExecutor.setWaitForTasksToCompleteOnShutdown(true);taskExecutor.setAwaitTerminationSeconds(60);//修改拒绝策略为使用当前线程执行taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());//初始化线程池taskExecutor.initialize();return taskExecutor;}
}

此时运行debug，可以看到不会启动报错，对应的线程池参数也是我们自定义的了

注意当我们上面自定义了线程池疑惑，@Sync对应的线程池也是我们自定义的这个，不会再采用默认的SimpleAsyncTaskExecutor

image-20240519225909829

默认的线程池好用吗？

TaskExecutionAutoConfiguration？

默认参数如下面所示：

  • 核心线程数 (corePoolSize): 8

  • 最大线程数 (maxPoolSize): Integer.MAX_VALUE (无限制)

  • 队列容量 (queueCapacity): Integer.MAX_VALUE (无限制)

  • 空闲线程保留时间 (keepAliveSeconds): 60秒

  • 线程池拒绝策略 (RejectedExecutionHandler): AbortPolicy（默认策略，超出线程池容量和队列容量时抛出RejectedExecutionException异常）

那么可能会有什么问题？

  1. 资源耗尽风险：由于最大线程数设置为Integer.MAX_VALUE，在高并发场景下，如果任务持续涌入，理论上可以创建无数线程，这将迅速消耗系统资源（如内存、CPU），可能导致服务器崩溃或极端性能下降。实际上，即使操作系统允许创建如此多的线程，这种设置也是极度不可取的。
  2. 响应性降低：虽然核心线程数设置为8是比较合理的起始点，但无限制的最大线程数意味着在高负载下，线程创建不会受限，这可能会影响到系统的响应时间和整体稳定性。过多的线程上下文切换会消耗大量CPU资源，降低处理效率。
  3. 队列无限增长：队列容量也设置为Integer.MAX_VALUE，这意味着当线程池中的线程都在忙碌且有新任务到来时，这些任务将不断堆积在队列中。如果生产速率持续高于消费速率，队列将无限增长，最终可能导致OutOfMemoryError。
  4. 异常处理策略过于简单粗暴：采用AbortPolicy作为拒绝策略，在线程池和队列都满载的情况下，新的任务提交将直接抛出RejectedExecutionException异常，而没有进行任何备份处理或降级策略，这可能会导致部分业务操作失败，且未被捕获处理的异常可能会影响到整个应用的稳定性。
  5. 缺乏灵活性和控制：对于不同的业务需求，线程池参数应当根据具体情况进行调整。例如，对响应时间敏感的服务可能需要更小的队列和更快的拒绝策略以避免任务长时间等待；而对于可延迟处理的任务，则可能需要更大的队列或不同的拒绝策略。

SimpleAsyncTaskExecutor

SimpleAsyncTaskExecutor 是Spring框架提供的一个简单的异步任务执行器，它并不是一个真正的线程池实现。它的主要特点是每次调用 #execute(Runnable) 方法时都会创建一个新的线程来执行任务。这意味着它不会重用线程，而是一次性的。

使用 SimpleAsyncTaskExecutor 可能会导致以下问题：

  1. 线程资源浪费： 每次执行任务时都创建新线程，这会导致线程的生命周期短暂，频繁地创建和销毁线程会消耗系统资源，包括CPU时间和内存。
  2. 系统资源耗尽： 在高并发场景下，如果大量任务同时提交，SimpleAsyncTaskExecutor 可能会创建大量线程，这可能会迅速耗尽系统资源，如线程数限制和内存资源。
  3. 缺乏线程管理： 真正的线程池通常包含线程管理机制，如线程重用、线程池大小控制、任务队列管理等。SimpleAsyncTaskExecutor 缺乏这些特性，因此在面对大量并发任务时可能无法有效地管理资源。
  4. 没有任务队列： 由于 SimpleAsyncTaskExecutor 不使用任务队列，它无法有效地缓冲任务。当任务提交速度超过执行速度时，新提交的任务可能会因为没有可用的线程而立即失败。
  5. 不适合长期运行的服务： 对于需要长期运行的服务，使用 SimpleAsyncTaskExecutor 可能会导致系统不稳定，因为它没有为长期运行的任务提供稳定的线程资源。

总结： SimpleAsyncTaskExecutor可以简单地用于异步任务执行，但由于它的设计限制，一般不推荐在生产环境中使用，特别是在要求高并发或资源使用高效的场景下。在这些情况下，更推荐使用可配置、可复用线程的线程池，如ThreadPoolTaskExecutor，因为它提供了更多的灵活性、效率和控制能力。

线程池核心线程数和最大线程数设置指南

线程池参数介绍
  • 核心线程数：线程池中始终活跃的线程数量。
  • 最大线程数：线程池能够容纳同时执行的最大线程数量。
线程数设置考虑因素
  1. CPU密集型任务：依赖CPU计算的任务，如循环计算等。
  2. IO密集型任务：任务执行过程中涉及等待外部操作，如数据库读写、网络请求、磁盘读写等。
CPU密集型任务的线程数设置
  • 推荐设置：核心数 + 1。
    • 原因：避免线程切换开销，同时允许一定程度的线程中断恢复。
IO密集型任务的线程数设置
  • 推荐设置：2 * CPU核心数。
    • 原因：IO操作期间，CPU可执行其他线程任务，提高资源利用率。
实际应用中的线程数计算
  • 使用工具（如Java的Visual VM）来监测线程的等待时间和运行时间。
  • 计算公式：（线程等待时间 / 线程总运行时间）+ 1 * CPU核心数。
生产环境中的线程数设置
  • 理论值与实际值可能存在差异，需要通过压力测试来确定最优线程数。
  • 压力测试：调整线程数，观察系统性能，找到最优解。
线程池参数设置建议
  • 核心业务应用：核心线程数设置为压力测试后的数值，最大线程数可以适当增加。
  • 非核心业务应用：核心线程数设置较低，最大线程数设置为压力测试结果
注意事项
  • 线程数设置需根据实际业务需求和系统环境进行调整。
  • 持续监控和优化是保证系统性能的关键。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/333015.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Samtec技术漫谈 | 电动自行车中的传感器和信号传输技术

Samtec技术漫谈 | 电动自行车中的传感器和信号传输技术

【摘要/前言】 电动自行车&#xff0c;大家熟悉吗&#xff1f; 今天的话题似乎是可以唤起大家心底骑车的美好回忆&#xff0c;我们也曾骑车探索过大自然和社区&#xff0c;自行车也是我们曾经不可或缺的便捷交通工具。 怀旧思潮的影响&#xff0c;加持科技的进步&#xff0c…
阅读更多...
Flask 蓝图路由的模块化开发

Flask 蓝图路由的模块化开发

基于 Flask 蓝图路由的模块化开发 1. 编程目标 为了提高Flask应用的可维护性和可扩展性&#xff0c;我们通过使用Flask的蓝图(Blueprint)功能&#xff0c;可以将不同的功能模块拆分到独立的文件中&#xff0c;方便后续的开发和维护。 2. 项目结构 项目结构树如下&#xff1…
阅读更多...
Uni-App开发 导入（引入）Vant-Weapp组件；支持vue3/vue2版本和微信小程序

Uni-App开发 导入（引入）Vant-Weapp组件；支持vue3/vue2版本和微信小程序

文章目录 目录 文章目录 操作流程 小结 概要安装流程技术细节小结 概要 Vant Weapp官网&#xff1a;Vant Weapp - 轻量、可靠的小程序 UI 组件库 准备工作&#xff0c;需要确保自己的电脑上已安装Hbuilde和node 全程操作的环境都需要这些配合才能运行上&#xff0c;可参考作者…
阅读更多...
M功能-支付平台(三)

M功能-支付平台(三)

target&#xff1a;离开柬埔寨倒计时-221day 前言 今天周六&#xff0c;但是在柬埔寨还是工作日&#xff0c;想着国内的朋友开始休周末就羡慕呀&#xff0c;记不清在这边过了多少个周六了&#xff0c;多到我已经习惯了。而且今天技术部还停电了&#xff0c;真的是热的受不了呀…
阅读更多...
【MATLAB源码-第74期】基于matlab的OFDM-IM索引调制系统不同频偏误码率对比，对比OFDM系统。

【MATLAB源码-第74期】基于matlab的OFDM-IM索引调制系统不同频偏误码率对比，对比OFDM系统。

操作环境&#xff1a; MATLAB 2022a 1、算法描述 OFDM-IM索引调制技术是一种新型的无线通信技术&#xff0c;它将正交频分复用&#xff08;OFDM&#xff09;和索引调制&#xff08;IM&#xff09;相结合&#xff0c;以提高频谱效率和系统容量。OFDM-IM索引调制技术的基本思想…
阅读更多...
Android 性能为王时代SparseArray和HashMap一争高下

Android 性能为王时代SparseArray和HashMap一争高下

文章目录 一、SparseArray 源码分析1. **类定义和构造函数**2. **基本方法**2.1 put(int key, E value)2.2 get(int key)2.3 delete(int key)2.4 removeAt(int index)2.5 gc()2.6 size()2.7 keyAt(int index) 和 valueAt(int index) 3. **辅助方法**3.1 binarySearch() 二、使用…
阅读更多...
【SpringCloud】负载均衡

【SpringCloud】负载均衡

目录 负载均衡什么是负载均衡生活场景为什么需要负载均衡负载均衡手段负载均衡总的来说有两种实现手段负载均衡具体可以通过多种手段来实现 SpringCloud中的负载均衡组件Ribbon VS Nginx负载均衡区别集中式LB进程内LB RibbonRibbon的工作原理Ribbon在工作时分成两步 使用1.提供…
阅读更多...
昔日辉煌不再，PHP老矣，尚能饭否？

昔日辉煌不再，PHP老矣，尚能饭否？

导语 | 近期 TIOBE 最新指数显示&#xff0c;PHP 的流行度降至了历史最低&#xff0c;排在第 17 名&#xff0c;同时&#xff0c;在年度 Stack Overflow 开发者调查报告中&#xff0c;PHP 在开发者中的受欢迎程度已经从之前的约 30% 萎缩至现在的 18%。“PHP 是世界上最好的语言…
阅读更多...
【开源】大学生竞赛管理系统 JAVA+Vue+SpringBoot+MySQL

【开源】大学生竞赛管理系统 JAVA+Vue+SpringBoot+MySQL

目录 一、系统介绍 学生管理模块 教师管理模块 竞赛信息模块 竞赛报名模块 二、系统截图 三、核心代码 一、系统介绍 基于Vue.js和SpringBoot的大学生竞赛管理系统&#xff0c;分为管理后台和用户网页端&#xff0c;可以给管理员、学生和教师角色使用&#xff0c;包括学…
阅读更多...
【Flutter】Dialog组件PageView组件

【Flutter】Dialog组件PageView组件

&#x1f525; 本文由 程序喵正在路上 原创&#xff0c;CSDN首发&#xff01; &#x1f496; 系列专栏&#xff1a;Flutter学习 &#x1f320; 首发时间&#xff1a;2024年5月27日 &#x1f98b; 欢迎关注&#x1f5b1;点赞&#x1f44d;收藏&#x1f31f;留言&#x1f43e; 目…
阅读更多...
如何确保大模型 RAG 生成的信息是基于可靠的数据源？

如何确保大模型 RAG 生成的信息是基于可靠的数据源？

在不断发展的人工智能 (AI) 领域中&#xff0c;检索增强生成 (RAG) 已成为一种强大的技术。 RAG 弥合了大型语言模型 (LLM) 与外部知识源之间的差距&#xff0c;使 AI 系统能够提供更全面和信息丰富的响应。然而&#xff0c;一个关键因素有时会缺失——透明性。 我们如何能够…
阅读更多...
mysql中单表查询的成本

mysql中单表查询的成本

大家好。我们知道MySQL在执行一个查询时&#xff0c;经常会有多个执行方案&#xff0c;然后从中选取成本最低或者说代价最低的方案去真正的执行查询。今天我们来聊一聊单表查询的成本。 那么到底什么是成本呢&#xff1f;这里我们说的成本或者代价是由两方面组成的&#xff1a…
阅读更多...
vscode插件-03 PHP

vscode插件-03 PHP

PHP Intelephense 如果php在远程计算机上&#xff0c;要把插件安装在远程&#xff0c;而不是本地。 这个插件&#xff0c;要求php版本大于7&#xff0c;且设置环境变量&#xff08;好像不一定要设置&#xff09;。 设置里面搜索php.executablePath&#xff0c;打开setting.js…
阅读更多...
element ui 的el-input输入一个字后失去焦点，需重新点击输入框才能再次输入

element ui 的el-input输入一个字后失去焦点，需重新点击输入框才能再次输入

解决方案&#xff1a; 我是form表单嵌套表格&#xff0c;里面的el-input输入框&#xff0c;输入第一个值的时候会突然失去焦点&#xff0c;需要再次点击输入框才能正常输入&#xff0c;原因是table的key值&#xff0c;需要改成正常的index即可&#xff0c;如果你是循环的&…
阅读更多...
ESP32入门：1、VSCode+PlatformIO环境搭建

ESP32入门：1、VSCode+PlatformIO环境搭建

文章目录 背景安装vscode安装配置中文 安装Platform IO安装PIO 新建ESP32工程参考 背景 对于刚接触单片机的同学&#xff0c;使用vscodeplatformIO来学习ESP32是最方便快捷的&#xff0c;比IDF框架简单&#xff0c;且比arduino文件管理性能更好。但是platformIO安装较为麻烦&a…
阅读更多...
gnocchi学习小结

gnocchi学习小结

背景 总结gnocchi 4.4版本gnocchi-metricd工作流程 入口 gnocchi.cli.metricd metricd stop after processing metric默认为0&#xff0c;调servicemanager run MetricdServiceManager __init__ 服务逻辑封装到MetricdServiceManager初始化中 主要由MetricProcessor, Met…
阅读更多...
【方法】ZIP压缩文件的密码如何设置和取消？

【方法】ZIP压缩文件的密码如何设置和取消？

ZIP是一种常见的压缩文件格式&#xff0c;今天来分享一下&#xff0c;ZIP压缩文件如何设置密码保护&#xff0c;以及如何取消密码&#xff0c;不清楚的小伙伴一起来看看吧&#xff01; 设置ZIP文件密码&#xff1a; 想要给ZIP压缩包设置密码&#xff0c;需要用到支持ZIP格式的…
阅读更多...
香橙派 Kunpeng Pro使用教程：从零开始打造个人私密博客

香橙派 Kunpeng Pro使用教程：从零开始打造个人私密博客

一、引言 在这个日益互联的世界中&#xff0c;单板计算机已经成为创新和个性化解决方案的重要载体。而在单板计算机领域&#xff0c;香橙派 Kunpeng Pro凭借其强大的性能和灵活的应用潜力&#xff0c;正逐渐吸引着全球开发者和技术爱好者的目光。 作为一款集成了华为的鲲鹏处…
阅读更多...
【AD21】文件的整理

【AD21】文件的整理

当所有文件输出完成后&#xff0c;需要对不同的文件去做一个整理&#xff0c;方便后续工作的交接。 在项目工程文件夹下新建名称为BOM、SMT、PRJ、Gerber和DOC的文件夹。 BOM文件夹存放BOM表发给采购人员。SMT文件夹存放装配图文件和坐标文件发给贴片厂。PRJ文件夹存放工程文件…
阅读更多...
AI大模型探索之路-实战篇4：深入DB-GPT数据应用开发框架调研

AI大模型探索之路-实战篇4：深入DB-GPT数据应用开发框架调研

目录 前言一、DB-GPT总体概述二、DB-GPT关键特性1、私域问答&数据处理&RAG2、多数据源&GBI3、多模型管理4、自动化微调5、Data-Driven Multi-Agents&Plugins6、隐私安全 三、服务器资源准备1、创建实例2、打开jupyterLab 四、DB-GPT启动1、激活 conda 环境2、切…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023