Spring @Async+CompletableFuture与Tomcat多线程性能对比及实现疑问

首先明确结论：你的实现方式没有发挥异步方案的优势，反而因为额外的线程切换开销拖慢了响应时间；在合理使用的场景下，异步方案能在系统吞吐量上超越Tomcat原生多线程，但单请求响应时间不一定更优。

为什么你的测试结果里Tomcat多线程更优？ #

你的代码存在几个关键问题，导致异步方案反而性能更差：

1. 无意义的线程切换
   你的Controller方法用@Async修饰，但方法内是同步完成所有逻辑（包括Service的DB调用），然后直接返回CompletableFuture.completedFuture(...)。这相当于把原本Tomcat线程可以直接完成的任务，额外放到asyncExecutor线程池里执行，多了一次线程上下文切换的开销，自然会增加响应时间。

2. 未利用CompletableFuture的并行能力
   CompletableFuture的核心价值是支持多任务并行执行，但你的代码里没有任何并行逻辑，只是用它包装了同步结果，完全浪费了它的异步并行特性。

3. 可能的线程池配置不合理
   如果asyncExecutor的核心线程数设置过小、队列长度过长，当并发请求进来时，任务会在队列中等待，无法及时执行，进一步拖慢响应速度。

什么时候异步方案能媲美甚至超越Tomcat多线程？ #

异步方案的优势在于释放Tomcat请求线程，提升系统吞吐量，同时在多IO任务并行时降低单请求响应时间，适用场景包括：

• Controller需要调用多个独立的IO密集型服务（比如多个DB查询、远程接口调用），可以用CompletableFuture.supplyAsync分别执行这些任务，再用CompletableFuture.allOf等待所有任务完成，最后合并结果。示例代码如下：

  @GetMapping("/somePath")
  public CompletableFuture<ResponseEntity<...>> someName(@RequestParam("someParam") String someParam) {
      // 并行执行多个IO任务
      CompletableFuture<String> task1 = CompletableFuture.supplyAsync(() -> service.method1(someParam), asyncExecutor);
      CompletableFuture<String> task2 = CompletableFuture.supplyAsync(() -> service.method2(someParam), asyncExecutor);
      
      return CompletableFuture.allOf(task1, task2)
          .thenApply(v -> {
              String result1 = task1.join();
              String result2 = task2.join();
              // 合并结果并返回
              return ResponseEntity.ok().body(mergeResult(result1, result2));
          })
          .exceptionally(e -> {
              // 异常处理
              return ResponseEntity.status(400).body(errorResponse(e));
          });
  }
  

• 业务逻辑中存在长时间的IO等待（比如大文件读写、慢DB查询），用异步方式让Tomcat线程不用一直阻塞等待，能更快处理其他请求。

关于性能的核心认知 #

• Tomcat多线程：每个请求占用一个Tomcat线程直到响应返回，适合CPU密集型或单IO任务场景，单请求响应时间可能更短（无额外线程切换），但吞吐量受限于Tomcat线程池大小。
• @Async + CompletableFuture：通过把IO密集型任务转移到自定义线程池，释放Tomcat线程，提升系统能处理的并发数；如果有并行任务，能减少单请求的总耗时。但如果是CPU密集型任务，线程切换的开销会抵消甚至超过异步带来的收益。

优化你的实现的建议 #

1. 移除Controller方法上的@Async，改用CompletableFuture处理并行任务（如上示例），避免无意义的线程切换。
2. 优化asyncExecutor的线程池配置：根据IO密集型任务的特点，核心线程数可以设置为2*CPU核心数或更高，队列长度不宜过长，避免任务堆积。
3. 尝试使用异步JDBC或Spring Data的异步查询（比如@Async修饰Service方法，返回CompletableFuture），让DB调用真正异步化，释放线程资源。

内容的提问来源于stack exchange，提问作者Pawan Gorai