线程池参数-SpringBoot配置线程池

最新推荐文章于 2025-02-15 18:45:25 发布
最新推荐文章于 2025-02-15 18:45:25 发布
阅读量977 收藏 6
点赞数 21
文章标签： spring boot java spring
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44797182/article/details/141724503
版权

先线程池有几个核心的参数概念：

  1. 核心线程数（corePoolSize）

    线程池中会维护一个最小的线程数量，即使这些线程处理空闲状态，他们也不会被销毁，除非设置了allowCoreThreadTimeOut。这里的最小线程数量即是corePoolSize。任务提交到线程池后，首先会检查当前线程数是否达到了corePoolSize，如果没有达到的话，则会创建一个新线程来处理这个任务。

  2. 最大线程数（maximumPoolSize）

    当前线程数达到corePoolSize后，如果继续有任务被提交到线程池，会将任务缓存到工作队列（后面会介绍）中。如果队列也已满，则会去创建一个新线程来出来这个处理。线程池不会无限制的去创建新线程，它会有一个最大线程数量的限制，这个数量即由maximunPoolSize指定。

  3. 活跃时间/空闲线程存活时间（keepAliveTime）

    一个线程如果处于空闲状态，并且当前的线程数量大于corePoolSize，那么在指定时间后，这个空闲线程会被销毁，这里的指定时间由keepAliveTime来设定

  4. 空闲线程存活时间的单位（unit）

    是指空闲线程存活时间的单位。keepAliveTime的计量单位。枚举类型TimeUnit类。线程空闲时间的单位，可以是秒、毫秒等。

  5. 阻塞队列/线程工作队列（workQueue）

    1. ArrayBlockingQueue FIFO有界阻塞队列
    2. LinkedBlockingQueue FIFO无限队列
    3. SynchronousQueue不缓存任务的阻塞队列
    4. PriorityBlockingQueue具有优先级的无界阻塞队列，优先级通过参数Comparator实现。

  6. 线程工厂（threadFactory）

    创建一个新线程时使用的工厂，可以用来设定线程名、是否为daemon线程等等，一般使用默认的ThreadFactory即可。

  7. 超出线程数和工作队列时候的任务请求处理策略/拒绝策略（handler）

    当工作队列中的任务已到达最大限制，并且线程池中的线程数量也达到最大限制，这时如果有新任务提交进来，该如何处理呢。对新任务的处理策略，可以是抛出异常、丢弃任务等。这里的拒绝策略，就是解决这个问题的，jdk中提供了4中拒绝策略：

    • 策略1：ThreadPoolExecutor.AbortPolicy（默认）拒绝执行
    • 策略2：ThreadPoolExecutor.CallerRunsPolicy调用 execute 方法的线程本身运行任务
    • 策略3：ThreadPoolExecutor.DiscardOldestPolicy执行程序未关闭，则删除工作队列头部的任务
    • 策略4：ThreadPoolExecutor.DiscardPolicy无法执行的任务被简单地删除
public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
原生使用
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(3, 10, 30, 
                                                           TimeUnit.SECONDS, 
                                                           new ArrayBlockingQueue<>(4),
                                                           Executors.defaultThreadFactory(), 
                                                           new ThreadPoolExecutor.DiscardOldestPolicy());

spring使用

配置文件
@Configuration
@EnableAsync
public class ThreadPoolConfig {
   /**
    * 下面的配置是配置Springboot的@Async注解所用的线程池
    */
   @Bean("taskExecutor")
   public Executor taskExecutor() {
       ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
       // 设置线程池核心容量
       executor.setCorePoolSize(4);
       // 设置线程池最大容量
       executor.setMaxPoolSize(8);
       // 设置任务队列长度
       executor.setQueueCapacity(200);
       // 设置线程超时时间
       executor.setKeepAliveSeconds(60);
       // 设置线程名称前缀
       executor.setThreadNamePrefix("xyjAsyncPool-");
       // 设置任务丢弃后的处理策略,当poolSize已达到maxPoolSize,如何处理新任务(是拒绝还是交由其它线程处理)
       // CallerRunsPolicy: 不在新线程中执行任务,而是由调用者所在的线程来执
       executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
       executor.initialize();
       return executor;
   }
}

配置测试接口及其实现类
public interface TestAsync {
   void doAsync();
}

@Service
@Slf4j
public class TestAsyncImpl implements TestAsync {
   @Override
   //使用@Async，并将前面的注册的bean，填写到Async的value中
   @Async("taskExecutor")
   public void doAsync() {
       log.info("== async start==");
       log.info("线程{}执行代码逻辑",Thread.currentThread().getName());
       log.info("== async end==");
   }
}

测试
@SpringBootTest
public class AsyncTest {
   //引用类
   @Autowired
   private TestAsync testAsync;

   @Test
   void test(){
       for (int i = 0; i < 10; i++) {
           testAsync.doAsync();
       }

   }
}
结果
2023-01-29 16:47:12.491  INFO 13332 --- [ taskExecutor-1] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.491  INFO 13332 --- [ taskExecutor-3] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.493  INFO 13332 --- [ taskExecutor-5] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.493  INFO 13332 --- [ taskExecutor-6] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.493  INFO 13332 --- [ taskExecutor-1] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.501  INFO 13332 --- [ taskExecutor-9] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.501  INFO 13332 --- [taskExecutor-10] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.500  INFO 13332 --- [ taskExecutor-7] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.502  INFO 13332 --- [ taskExecutor-8] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.500  INFO 13332 --- [ taskExecutor-7] c.w.a.service.async.impl.TestAsyncImpl   : == async start==
2023-01-29 16:47:12.502  INFO 13332 --- [ taskExecutor-6] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-6执行代码逻辑
2023-01-29 16:47:12.501  INFO 13332 --- [ taskExecutor-8] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-8执行代码逻辑
2023-01-29 16:47:12.503  INFO 13332 --- [ taskExecutor-5] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.492  INFO 13332 --- [ taskExecutor-9] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-9执行代码逻辑
2023-01-29 16:47:12.503  INFO 13332 --- [ taskExecutor-2] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.503  INFO 13332 --- [ taskExecutor-7] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.501  INFO 13332 --- [ taskExecutor-9] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-9执行代码逻辑
2023-01-29 16:47:12.492  INFO 13332 --- [ taskExecutor-1] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-1执行代码逻辑
2023-01-29 16:47:12.506  INFO 13332 --- [ taskExecutor-1] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.506  INFO 13332 --- [ taskExecutor-9] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.493  INFO 13332 --- [ taskExecutor-3] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-3执行代码逻辑
2023-01-29 16:47:12.501  INFO 13332 --- [taskExecutor-10] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-10执行代码逻辑
2023-01-29 16:47:12.506  INFO 13332 --- [ taskExecutor-3] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.506  INFO 13332 --- [taskExecutor-10] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.502  INFO 13332 --- [ taskExecutor-8] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-8执行代码逻辑
2023-01-29 16:47:12.506  INFO 13332 --- [ taskExecutor-8] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.502  INFO 13332 --- [ taskExecutor-7] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-7执行代码逻辑
2023-01-29 16:47:12.508  INFO 13332 --- [ taskExecutor-7] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
2023-01-29 16:47:12.493  INFO 13332 --- [ taskExecutor-4] c.w.a.service.async.impl.TestAsyncImpl   : 线程taskExecutor-4执行代码逻辑
2023-01-29 16:47:12.508  INFO 13332 --- [ taskExecutor-4] c.w.a.service.async.impl.TestAsyncImpl   : == async end==
SpringBoot线程池配置和使用
no_can_no_bb_的博客
10-17 4106
配置文件： #spring线程池 task-executor: core_pool_size: 5 max_pool_size: 10 queue-capacity: 20 name-prefix: async-service- 线程池配置类： @Configuration @EnableAsync public class TaskExecutorConfig { ...
Spring Boot 线程池配置详解
最新发布
Logan的博客
04-10 874
I/O 密集型任务‌ 核心线程数 = CPU 核心数 × 2，队列容量较大 异步文件处理、网络请求。建议‌：根据任务类型设定（如 I/O 密集型任务可设为 CPU 核心数 × 2）‌。作用‌：线程池中始终保持存活的线程数量，即使空闲也不回收‌。作用‌：线程池允许创建的最大线程数，仅在队列满时触发扩容‌。建议‌：设置为核心线程数的 2~3 倍，避免资源耗尽‌。作用‌：任务缓冲队列的大小，决定线程池的请求处理能力‌。作用‌：非核心线程空闲时的最大存活时间（单位：秒）‌。
SpringBoot配置线程池
YIYIYI
12-16 4615
SpringBoot配置线程池
Springboot配置线程池
coderrrrrr的博客
05-02 6304
（1）：核心线程数，指的是核心线程大小，线程池中维护一个最小的线程数量，即使这些线程处于空闲状态，也一直存在池中，除非设置了。（2）：最大线程数，指的是。（3）：空闲线程存活时间，具体说，当线程数大于核心线程数时，空闲线程在等待新任务到达的最大时间，如果超过这个时间还没有任务请求，该空闲线程就会被销毁。（4）：空闲线程存活时间的单位，keepAliveTime的计量单位。枚举类型TimeUnit类。（5）
Springboot线程池配置
Ricardo.M.Yu的博客
11-15 9654
Springboot线程池配置
Springboot实现多个线程池动态配置
t194978的博客
12-24 732
我这里的配置user线程池配置最多只能执行4个任务，超过则提示，school线程池最多只能执行3个任务，超过则提示，我在页面调接口创建线程执行分别执行user线程池和school线程池，连续请求4次，预期结果应该是user线程池可以正常执行，school线程池则会提示。nacos新建线程池专用的配置文件，注意推荐使用properties类型的配置文件，yaml类型的会读取不全配置信息的问题。去nacos中修改一下线程池的配置，把user线程修改成最多只有2个任务执行，school线程最多只有4个任务执行。
springcloud配置中心nacos动态线程池Dynamic-tp配置接入实战
Java_zhujia的博客
12-22 2368
最近业务上需要把项目组几个微服务接入动态线程池框架Dynamic-tp监控，同时支持webhook机器人接受变更通知、容量报警、活性报警、拒绝报警、任务超时报警等通知，方便项目组同事企业微信群实时监控线程池状态，动态调整线程参数。接手开始上手，一看网上教程和demo很多啊，心中窃喜，一顿ctrl+c+v大发，却发现告警不通知，配置线程池不生效，数着承诺的交付时间，开始发慌；几经周折，才定，斯文于记。
线程池结合SpringBoot
m0_61802230的博客
05-09 1284
导读 什么是线程池 线程池（Thread Pool）是一种基于池化思想管理线程的工具，经常出现在多线程服务器中，如MySQL。 创建线程本身开销大，反复创建并销毁，过多的占用内存。所以有大量线程创建考虑使用线程池。线程池不用反复创建线程达到线程的复用，更具配置合理利用cpu和内存减少了开销，性能会得到提高，还能统一管理任务 比如服务器收到大量请求，每个请求都分配线程去处理，对服务器性能考验就比较大，如果创建5个以上线程考虑使用线程池。 线程过多会带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等
springboot 配置线程池
lsh894609937的专栏
08-28 1627
1.添加配置类 @Configuration @EnableAsync public class ThreadPoolConfig { @Bean("taskExecutor") public TaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor...
SpringBoot线程池的使用
web15185420056的博客
02-15 1150
通过合理配置和使用线程池，Spring Boot应用可以更好地处理并发任务，提高系统的性能和响应速度。配置线程池时，需要根据具体的业务场景选择合适的参数，如核心线程数、最大线程数、队列容量等。同时，还需要考虑任务的性质，选择合适的拒绝策略来处理超出线程池处理能力的任务。
Spring线程池配置
02-11
数据库连接是一种关键的有限的昂贵的资源，这一点在多用户网页应用程序中体现的尤为突出。对数据库连接的管理能显著影响到整个应用的伸缩性和健壮性，影响到程序的性能指标。
SpringBoot线程池配置
qq_41349627的博客
09-07 316
【代码】SpringBoot线程池配置。
Spring boot配置线程池：
苦逼打工人的博客
08-28 5724
spring boot线程池配置以及怎么使用（附带源码）
SpringBoot 线程池的配置
weixin_43607664的博客
06-17 868
SpringBoot 线程池的配置 import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.annotation.EnableAsync; import
springBoot配置线程池
dj1955的博客
09-17 1668
springBoot配置线程池
springboot线程池配置使用
CCkaroy的博客
04-27 9518
在网上看到了很多的配置的文章，但感觉用起来怪怪的，自己总结下。 1.基本的配置 这边在基本的配置上面都是大同小异，几个核心的参数也都有合适的一些值，网上都有说明，不在赘述。springboot线程池配置方法_xiegongmiao的博客-CSDN博客_springboot线程池配置 这边说一下返回的Executor类，网上也有使用ExecutorService的。 线程池学习 ，Executor 与 ExecutorService 和 Executors的区分_码上不知人间事的博客-CSDN博客
yolo11-seg和yolo11-detect有什么区别
03-16
<think>好的，我现在需要回答用户关于YOLOv11-seg和YOLOv11-detect之间的区别，特别是功能实现方面的差异。首先，我需要回忆YOLO系列模型的基本知识，尤其是分割（segmentation）和检测（detection）任务的不同之处。 用户提到的YOLOv11-seg和YOLOv11-detect，可能是指同一版本YOLO的不同变体，分别用于分割和检测。检测任务通常是识别图像中的物体并给出边界框和类别，而分割任务则需要更精确的像素级分类，即每个像素属于哪个物体或类别。因此，两者的模型结构可能在输出层或头部设计上有所不同。 接下来，我需要参考用户提供的引用内容。引用[1]提到了导出YOLO模型为ONNX格式，可能涉及模型的结构和输出。引用[2]讨论了使用RKNN进行部署，说明两者都需要优化以适应硬件，但具体的结构差异可能影响部署时的处理方式。例如，分割模型可能输出更多的数据（如掩膜），需要不同的后处理步骤。 然后，我需要详细比较两者的功能实现。检测模型通常输出边界框、类别置信度和类别概率，而分割模型除此之外还会输出每个实例的掩膜。因此，YOLOv11-seg可能在检测头的基础上添加了掩膜预测分支，或者使用不同的解码方式。例如，YOLO的实例分割模型如YOLACT或YOLOv5-seg，通常会在检测的基础上通过原型掩膜和系数矩阵生成实例分割结果。 另外，训练数据方面，检测模型需要边界框标注，而分割模型需要像素级的掩膜标注。这可能导致两者的训练过程和损失函数不同，分割模型的损失可能包括掩膜的交叉熵损失或Dice损失等。 用户还可能关心性能和应用场景。分割模型由于需要处理更多数据，可能计算量更大，推理速度较慢，适合需要精确轮廓的应用，如医学图像分析或自动驾驶中的场景理解。而检测模型更适用于实时性要求高的场景，如视频监控或移动端应用。 最后，我需要确保回答结构清晰，符合用户要求，使用正确的LaTeX格式，并生成相关问题。同时，引用用户提供的两个引用，但注意引用内容是否直接相关。引用[2]提到的是姿态估计的部署，可能与分割和检测的差异无直接关系，但可以说明不同任务模型在部署时的优化需求类似。需要确认引用是否适用于当前问题，或是否需要调整引用标注。</think>### YOLOv11-seg与YOLOv11-detect的功能实现差异 YOLOv11-seg（实例分割模型）和YOLOv11-detect（目标检测模型）在功能实现上的核心区别在于**任务目标与输出形式**。以下是具体分析： --- #### 1. **任务目标** - **YOLOv11-detect** 专注于**目标检测**，即定位图像中的物体并输出其边界框（Bounding Box）、类别标签及置信度。例如，在图像中标注“狗”的位置和类别。 **数学表示**：输出形式为$B = (x, y, w, h, c)$，其中$(x, y)$为中心坐标，$(w, h)$为宽高，$c$为类别概率。 - **YOLOv11-seg** 在检测基础上增加**实例分割**功能，需额外生成每个物体的像素级掩膜（Mask）。例如，在标注“狗”的边界框时，还需精确标记其轮廓的每个像素[^1]。 **数学表示**：输出包含掩膜矩阵$M \in \mathbb{R}^{H \times W}$，其中$H \times W$为图像分辨率，值表示像素是否属于目标。 --- #### 2. **模型结构差异** - **检测头部（Detection Head）** - **YOLOv11-detect**：通过卷积层直接预测边界框坐标和类别概率。 - **YOLOv11-seg**：在检测头部基础上增加**掩膜预测分支**，通常结合原型掩膜（Prototype Masks）和掩膜系数矩阵生成实例分割结果[^1]。例如： $$M = \sigma(P \cdot C)$$ 其中$P$为原型掩膜，$C$为检测头输出的系数矩阵，$\sigma$为激活函数。 - **后处理** - **YOLOv11-detect**：仅需非极大值抑制（NMS）筛选重叠框。 - **YOLOv11-seg**：需对掩膜进行阈值化和轮廓优化，计算量更大。 --- #### 3. **训练数据与损失函数** - **训练数据** - 检测模型：依赖标注的边界框（COCO等数据集）。 - 分割模型：需额外掩膜标注（如COCO的`segmentation`字段）。 - **损失函数** - 检测模型：边界框损失（如CIoU）、分类损失（交叉熵）。 - 分割模型：需叠加掩膜损失（如Dice Loss或二进制交叉熵）。 --- #### 4. **应用场景与性能** - **YOLOv11-detect** 适用于实时性要求高的场景，如视频监控、自动驾驶中的障碍物检测。 **优点**：推理速度快，资源占用低。 - **YOLOv11-seg** 适合需要精确物体轮廓的任务，如医学图像分析、机器人抓取。 **缺点**：计算复杂度高，需更多显存和算力[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值