当前位置: 首页 > news >正文

Spring Boot 中基于线程池的订单创建并行化实践

一、背景

1.1 业务背景

  • 以电商系统「订单创建」接口为例

  • 一个用户下单请求,往往需要完成多个业务步骤:

    • 校验库存

    • 校验用户信息

    • 计算订单价格

    • 锁库存

    • 创建订单

1.2 问题描述

  • 传统实现方式:串行执行

  • 在高并发场景下:

    • 接口 RT 高

    • 线程被长时间占用

    • 系统吞吐下降

1.3 技术挑战

  • 哪些任务可以并行?

  • 如何安全、高效地并行?

  • 如何在 Spring Boot 中正确使用线程池

  • 二、业务场景分析与并行拆分

    2.1 订单创建流程拆解

    步骤是否存在依赖是否可并行
    校验库存
    校验用户
    计算价格
    锁库存依赖库存校验
    创建订单依赖前置结果

    2.2 并行化设计思路

  • 无依赖的校验类任务 → 并行

  • 存在业务依赖的核心流程 → 串行

  • 线程池只用于短生命周期任务

三、技术选型与整体设计

3.1 为什么不直接 new Thread?

  • 线程创建成本高

  • 无法控制并发量

  • 高并发下容易导致 JVM 失控

3.2 为什么选择线程池 + CompletableFuture?

  • 线程复用,降低系统开销

  • 明确的并发上限

  • 支持任务编排(allOf / thenCombine)

3.3 在 Spring Boot 中的正确姿势

  • 线程池必须交由 Spring 管理

  • 使用ThreadPoolTaskExecutor

  • 为业务定制专用线程池,避免互相影响

四、线程池设计与配置(Core)

4.1 线程池配置代码

@Configuration public class OrderThreadPoolConfig { @Bean("orderExecutor") public ThreadPoolTaskExecutor orderExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix("order-create-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }

4.2 关键参数说明

  • corePoolSize:常态并发能力

  • maxPoolSize:应对突发流量

  • queueCapacity:缓冲任务,防止雪崩

  • RejectedExecutionHandler

    • 选择CallerRunsPolicy实现自然限流

4.3 线程池定位

  • Web 请求内使用

  • IO + 轻计算混合型线程池

  • 非长任务、非阻塞型任务

五、核心业务实现

5.1 校验 Service(模拟 RPC / DB)

@Service public class OrderCheckService { public boolean checkStock(Long skuId) { sleep(100); return true; } public boolean checkUser(Long userId) { sleep(80); return true; } public int calcPrice(Long skuId) { sleep(120); return 99; } private void sleep(long ms) { try { Thread.sleep(ms); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }

5.2 订单创建核心逻辑

@Service public class OrderService { @Resource(name = "orderExecutor") private Executor orderExecutor; @Autowired private OrderCheckService orderCheckService; public String createOrder(Long userId, Long skuId) throws Exception { long start = System.currentTimeMillis(); CompletableFuture<Boolean> stockFuture = CompletableFuture.supplyAsync( () -> orderCheckService.checkStock(skuId), orderExecutor); CompletableFuture<Boolean> userFuture = CompletableFuture.supplyAsync( () -> orderCheckService.checkUser(userId), orderExecutor); CompletableFuture<Integer> priceFuture = CompletableFuture.supplyAsync( () -> orderCheckService.calcPrice(skuId), orderExecutor); CompletableFuture.allOf( stockFuture, userFuture, priceFuture).join(); if (!stockFuture.get()) { throw new RuntimeException("库存不足"); } int price = priceFuture.get(); lockStock(skuId); saveOrder(userId, skuId, price); return "success, cost=" + (System.currentTimeMillis() - start) + "ms"; } private void lockStock(Long skuId) { sleep(50); } private void saveOrder(Long userId, Long skuId, int price) { sleep(80); } private void sleep(long ms) { try { Thread.sleep(ms); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }

5.3 Controller

@RestController @RequestMapping("/order") public class OrderController { @Autowired private OrderService orderService; @PostMapping("/create") public String createOrder( @RequestParam Long userId, @RequestParam Long skuId) throws Exception { return orderService.createOrder(userId, skuId); } }

六、JMeter 压测与结果分析

6.1 压测配置说明

  • 并发线程数:200

  • Ramp-Up:1 秒


6.2 压测现象

  • 系统启动初期:

    • 接口 RT ≈288ms

  • 持续压测后:

    • RT 逐渐上升

    • 峰值约1888ms


6.3 原因分析

  1. 每个请求会向线程池提交3 个并行任务

  2. 200 个并发请求 ≈600 个线程池任务

  3. 线程池最大并发执行数为16

  4. 多余任务进入阻塞队列

  5. 队列满后触发CallerRunsPolicy

  6. 部分任务由HTTP 工作线程执行,导致请求处理时间变长


6.4 工程结论

  • RT 上升并不代表线程池失效

  • 这是线程池在高并发下的自我保护行为

  • 相比无限创建线程导致系统崩溃,RT 变慢是一种可接受的退化方式

线程池优化的是系统吞吐与稳定性,而不是在无限并发下保持恒定响应时间。

七、问题思考

7.1 为什么不用 @Async?

  • 难以进行复杂任务编排

  • 不利于精细化控制线程池

7.2 为什么不用 parallelStream?

  • 使用公共 ForkJoinPool

  • 线程资源不可控

7.3 线程池并非万能

  • 仍需配合限流、熔断等机制

  • 核心链路与非核心链路应区别对待

http://www.jsqmd.com/news/132288/

相关文章:

  • APKMirror安卓应用商店完整使用指南:从下载到上传的全面解析
  • 安卓应用下载终极指南:5分钟掌握安全下载技巧
  • [缩略语大全]之[计算机图形学]篇
  • BthPS3驱动:让PS3蓝牙控制器在Windows上重获新生
  • BG3ModManager终极指南:快速上手博德之门3模组管理
  • 碳中和目标下,Anything-LLM助力ESG报告智能生成
  • 航空航天领域技术文档复杂?Anything-LLM助工程师提效
  • 一文说清毛球修剪器电路图的基本组成结构
  • 百度网盘SVIP优化工具:macOS用户专属的极速下载方案
  • 12个STM32实战项目开发指南:从入门到精通的嵌入式系统设计
  • 10个必学的VLC媒体播放器技巧:从入门到精通完全指南
  • PL2303驱动完美兼容Windows 10:彻底解决串口通信难题
  • 终极解决方案:让PS3手柄在Windows电脑上完美工作的完整指南
  • 通达信缠论可视化插件:让复杂技术分析变得简单高效
  • LyricsX使用全攻略:打造个性化歌词显示体验
  • 图解说明毛球修剪器电路图中开关控制回路
  • AI自动化框架如何实现跨平台智能控制?深度解析Midscene.js技术架构
  • 基于FPGA的加法器设计:完整指南
  • 惠普暗影精灵笔记本性能控制终极指南:OmenSuperHub全面评测
  • 边缘计算+Anything-LLM:离线环境下的AI文档助手可能吗?
  • 美团小程序最新 mtgsig
  • 一键部署、极速启动——Anything-LLM Docker镜像使用技巧
  • Mac百度网盘加速终极方案:突破下载限制的技术指南
  • 5分钟玩转JSON可视化:用JSONEditor让复杂数据结构一目了然
  • 最新小程序 mtgsig1.2
  • 多语言文档处理能力评测:Anything-LLM国际化支持进展
  • Windows平台PS3手柄蓝牙驱动完全解决方案
  • Midscene.js:用AI视觉技术重新定义浏览器自动化的颠覆性方案
  • CREO到URDF转换终极指南:5步实现机器人模型自动化生成
  • TouchGal:一站式Galgame社区平台完整指南