10 万QPS ，API 耗时 100ms，线程池如何优化？

• 一、背景介绍：什么场景下会遇到这种问题？
• 二、问题分析：常规线程池会怎样？
• 三、优化目标
• 四、解决方案：线程池优化策略
• 五、代码实现：线程池优化实战（含注释）
• 六、进阶优化建议
• 七、总结

在一次处理大促活动中的任务系统时，我们遇到了这样的需求：

• 接口吞吐量：QPS 高达 100,000（10 万）
• 每个任务处理平均耗时：100ms
• 每个请求都需要进线程池执行处理逻辑（比如发通知、写日志、异步落库等）
• 要求整体系统稳定、响应快、资源利用率高

如果不加优化，线程池很容易撑爆 CPU 和内存，甚至引发系统雪崩。

举个例子

如果我们不做优化，简单使用 Java 默认线程池配置：

Executors.newFixedThreadPool(100);

面对 10 万 QPS 的请求，每个任务耗时 100ms：

• 每秒需要处理 100000 个任务
• 每个任务需要 100ms，也就是每个线程每秒最多处理 10 个请求
• 所以至少需要：100000 / 10 = 10000 个线程才能撑住！

我们要实现的目标是：

• 控制线程数，避免线程爆炸
• 提升吞吐能力，让单个线程处理更多任务
• 合理使用队列和限流，避免系统雪崩
• 提供平稳退化机制：拒绝策略、降级处理

✅ 核心策略如下：

我们以 Spring Boot + 自定义线程池为例，构建一个高性能任务处理系统。

1. 线程池配置类

@Configuration
publicclassThreadPoolConfig {

    @Bean("taskExecutor")
    public ThreadPoolExecutor taskExecutor() {
        intcorePoolSize=200;      // 核心线程数
        intmaxPoolSize=500;       // 最大线程数
        intqueueCapacity=10000;   // 队列容量
        intkeepAliveTime=60;      // 非核心线程最大空闲时间（秒）

        returnnewThreadPoolExecutor(
            corePoolSize,
            maxPoolSize,
            keepAliveTime,
            TimeUnit.SECONDS,
            newLinkedBlockingQueue<>(queueCapacity),
            newThreadFactory() {
                privatefinalAtomicIntegercount=newAtomicInteger(0);

                @Override
                public Thread newThread(Runnable r) {
                    returnnewThread(r, "task-executor-" + count.getAndIncrement());
                }
            },
            newRejectedExecutionHandler() {
                @Override
                publicvoidrejectedExecution(Runnable r, ThreadPoolExecutor executor) {
                    // 自定义拒绝策略：记录日志 + 降级处理
                    System.err.println("任务被拒绝执行：" + r.toString());
                    // 可以添加报警、入备用队列等逻辑
                }
            }
        );
    }
}

2. 业务层异步任务提交

@Service
publicclassTaskService {

    @Resource(name = "taskExecutor")
    private ThreadPoolExecutor taskExecutor;

    /**
     * 接收高并发请求，异步处理任务
     * @param taskId 任务ID
     */
    publicvoidsubmitTask(String taskId) {
        taskExecutor.execute(() -> {
            longstart= System.currentTimeMillis();
            try {
                // 模拟任务耗时处理
                Thread.sleep(100); // 实际场景可为远程调用、数据库操作等

                System.out.println(Thread.currentThread().getName()
                    + " 执行任务 [" + taskId + "] 成功，耗时：" +
                    (System.currentTimeMillis() - start) + "ms");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
    }
}

3. Controller 接口模拟压测

@RestController
@RequestMapping("/api/task")
public class TaskController {

    @Autowired
    private TaskService taskService;

    /**
     * 模拟高并发任务提交接口
     * @param taskId 任务ID
     */
    @PostMapping("/submit")
    public ResponseEntity<String> submit(@RequestParam String taskId) {
        taskService.submitTask(taskId);
        return ResponseEntity.ok("任务已提交");
    }
}

1. 使用 Disruptor 或 LMAX RingBuffer 替代线程池

对于毫秒级、极限吞吐量场景，可以使用 Disruptor（单线程+无锁队列），吞吐量可达百万 QPS。

2. 异步合并 + 批处理

例如每 100ms 收集一批任务，一次性处理：

// 使用 ScheduledExecutorService 定时拉取任务批处理，提高 CPU 利用率，减少线程切换

// 或者使用 RxJava/Project Reactor 等响应式框架处理

3. 限流 + 熔断 + 降级

利用 Sentinel 或 Resilience4j 对接口加限流、熔断保护：

// 限流策略：如每秒只允许 10w 请求进入线程池
// 熔断策略：连续失败时自动拒绝请求，避免故障蔓延

面对 QPS 10 万、任务耗时 100ms 的高并发场景，线程池优化是重中之重。我们从业务特性出发，结合线程池的核心参数配置，设计了合理的任务分发机制。

优化线程池的关键在于：限制并发、提升单线程效率、合理拒绝请求、异步批处理。

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：
  

  

   

    

     一张图看懂微服务架构路线

    
   

    

     基于Spring Cloud的微服务架构分析
    
   

    

     微服务等于Spring Cloud？了解微服务架构和框架

    
   

    

     如何构建基于 DDD 领域驱动的微服务？
    
   
小团队真的适合引入SpringCloud微服务吗？

   
DDD兴起的原因以及与微服务的关系
   
微服务之间的最佳调用方式

   
微服务架构设计总结实践

   
基于 Kubernetes 的微服务项目设计与实现
   
微服务架构-设计总结
   
为什么微服务一定要有网关？
   
主流微服务全链路监控系统之战

   

    

     微服务架构实施原理详解

    
   

    

     微服务的简介和技术栈
    
   

    

     微服务场景下的数据一致性解决方案
    
   

    

     设计一个容错的微服务架构