克拉玛依市网站建设_网站建设公司_外包开发_seo优化

一、背景

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 线程池并非万能

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

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