# MVC Async 工程冲突与价值：从同步阻塞到异步释放 Servlet 线程

```text
旧方案：同步生成宠物健康报告，Servlet 线程阻塞等待慢查询与统计
冲突：并发一高，Tomcat 工作线程被占满，普通请求排队超时
后果：接口 P99 飙升，健康检查失败，扩容治标不治本
```

Petclinic 原本的宠物健康报告接口是同步执行，请求进来后从数据库拉取宠物档案、疫苗记录、体重曲线，再汇总成报告。

数据量小的时候没问题，一旦诊所接入历史数据或第三方检测结果，单次生成可能从几十毫秒涨到几秒。

我是老李，深圳南山一家宠物医疗 SaaS 团队的架构师。

我们线上 Tomcat 默认 200 个工作线程，压测时发现 40 个并发就能把线程池打满，因为每个慢报告请求都占着一个 Servlet 线程干等。

为什么同步慢接口会拖垮整个 Tomcat 线程池？

应该用 Callable、DeferredResult、WebAsyncTask 还是 SSE 来释放 Servlet 线程？

如果选错异步模型或忽略超时与客户端断开，会不会造成线程池泄漏或结果永远无法返回？

# 01、故事

```text
周二 14:30→深圳南山科兴科学园→给 Petclinic 加宠物健康报告接口→压测 40 并发线程池耗尽
```

周二下午两点半，深圳南山科兴科学园 B 栋 12 楼，会议室白板上画着 Petclinic 的调用链。任务是给宠物健康报告接口做异步化改造，因为上午客户演示时 40 个并发直接把测试环境打挂。

运维在群里催：“Tomcat 线程池 active 200，队列 800，健康检查开始超时。”我打开 VisualVM 一看，http-nio-8080-exec 线程全部卡在 JDBC 查询上。

产品经理站在旁边问：“不就是加个接口吗，怎么把整个服务都拖垮了？”我一边回滚一边想，同步模型下 Servlet 线程和业务执行线程是同一个，慢逻辑不结束，线程不归还。

> 南山午后雨未停，
> 线程池满警报鸣。
> 慢查未归连接紧，
> 回滚之后待天明。

# 02、问题

```text
需求变化：报告从单表查询变成多源聚合
冲突：同步执行让 Servlet 线程等待慢逻辑
后果：Tomcat 线程池耗尽，普通请求无法进入
```

V1 同步接口的问题不是代码写错，而是执行模型不匹配。当报告生成从单表查询变成多源聚合后，单次耗时从 80ms 涨到 3 秒以上，Servlet 线程在这 3 秒里只做等待，不处理任何其他请求。

Tomcat 默认最大工作线程数有限，一旦慢请求占比升高，线程池会迅速被占满。此时即使有 CPU 空闲，新请求也只能在连接队列里排队，表现为全局响应变慢。

可验证的验收标准是：用 JMeter 以 50 并发压测同步接口，观察 Tomcat 当前工作线程数是否接近最大值，同时普通健康检查接口的响应时间是否从 10ms 涨到 2 秒以上。

> 慢查如石沉深井，
> 一线线程空自等。
> 池中无兵可调度，
> 门外请求叹长更。

# 03、原理

```text
Servlet 线程 → 提交异步任务到 AsyncExecutor → 立即释放 → 任务完成后重新 dispatch 回 DispatcherServlet
```

Spring MVC Async 的核心机制是：请求进入 DispatcherServlet 后，Controller 返回 Callable 或 DeferredResult，容器把任务交给独立的

AsyncExecutor 执行，Servlet 线程立即归还给 Tomcat 线程池。

任务完成后，Spring 会重新 dispatch 一个请求回到 DispatcherServlet，走结果处理流程，把响应写回客户端。

这个重新 dispatch 的过程会再次占用一个 Servlet 线程，但只用于写结果，时间极短。

反直觉判断：MVC Async 不会让慢 SQL 或 CPU 密集算法变快，它只是把“等待”从 Servlet 线程转移到业务线程池。

如果业务线程池也满了，任务依然会排队，只是不再阻塞 Tomcat 接收新请求。

> 一线让出千军路，
> 慢活移入别院中。
> 归来再借三分力，
> 只写回执不写工。

# 04、架构

```text
输入：HTTP 请求 → DispatcherServlet → Controller 返回异步包装
输出：AsyncExecutor 执行慢逻辑 → 重新 dispatch → 响应写回
边界：超时、异常、客户端断开必须显式处理
```

异步架构分三层：接入层由 Tomcat 工作线程负责接收请求和写回响应；调度层由 Spring MVC Async 管理异步上下文和超时；执行层由业务线程池负责跑慢逻辑。

收益是 Servlet 线程占用时间从秒级降到毫秒级，Tomcat 可以接收更多并发连接。代价是引入第二个线程池，需要管理队列、拒绝策略和线程数。

适用条件是慢逻辑以 IO 等待为主，比如远程调用、消息队列、长轮询。如果慢逻辑是纯 CPU 计算，异步化只会增加线程切换开销，不会提升吞吐。

> 接入如门迎客往，
> 调度如令传四方。
> 执行如匠埋头做，
> 边界如墙防漏光。

# 05、第一版实战

```text
环境：Spring Boot 3.2 + Spring Framework 6.1 + Tomcat 10.1
配置：AsyncExecutor 线程池
代码：Callable 包装慢逻辑
启动：mvn spring-boot:run
验证：curl 请求 + 日志观察线程名
V1：Callable 异步化
```

先建一个 Spring Boot 项目，依赖 spring-boot-starter-web。

版本需按当前官方文档核验，本示例使用 Spring Boot 3.2 与 Spring Framework 6.1。

配置异步线程池：

```java
@Configuration
public class AsyncConfig implements WebMvcConfigurer {
    @Override
    public void configureAsyncSupport(AsyncSupportConfigurer configurer) {
        configurer.setTaskExecutor(asyncExecutor());
        configurer.setDefaultTimeout(5000);
    }

    @Bean(name = "asyncExecutor")
    public ThreadPoolTaskExecutor asyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(20);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("pet-async-");
        executor.initialize();
        return executor;
    }
}
```

Controller 返回 Callable：

```java
@RestController
@RequestMapping("/api/reports")
public class ReportController {
    @GetMapping("/{petId}/health")
    public Callable<HealthReport> generateHealthReport(@PathVariable Long petId) {
        return () -> {
            // 模拟多源聚合慢逻辑
            Thread.sleep(3000);
            return new HealthReport(petId, "正常", "2025-01-01");
        };
    }
}
```

启动应用：

```bash
mvn spring-boot:run
```

验证请求：

```bash
curl -i http://localhost:8080/api/reports/1/health
```

示例输出：

```text
HTTP/1.1 200
Content-Type: application/json

{"petId":1,"status":"正常","date":"2025-01-01"}
```

成功标准：请求返回 200，日志中能看到 http-nio-8080-exec 线程先返回，pet-async-1 线程执行慢逻辑，完成后再次出现 http-nio-8080-exec 线程写响应。

> 一线提交转身去，
> 异步池中慢工忙。
> 三秒归来重借道，
> 回执写罢各一方。

# 06、排查

```text
诊断树：请求超时 → 是 AsyncExecutor 队列满？→ 是超时时间太短？→ 是客户端断开未处理？
```

问题一：压测时大量请求返回 503，日志出现 AsyncRequestTimeoutException。

怀疑是默认超时时间太短，检查配置发现没有设置 defaultTimeout，Spring 默认 30 秒，但 JMeter 客户端超时设了 3 秒。

检查命令：

```bash
curl -i -m 3 http://localhost:8080/api/reports/1/health
```

证据是 curl 在 3 秒时断开，服务端日志随后抛出 AsyncRequestTimeoutException。

根因是客户端超时与服务端超时不一致，客户端先断开，服务端还在执行任务。

修复方式是统一超时时间，并在客户端断开时取消任务。

问题二：并发 100 时，部分请求进入队列等待超过 5 秒。怀疑是线程池配置太小，检查线程池状态：

```java
ThreadPoolTaskExecutor executor = (ThreadPoolTaskExecutor) context.getBean("asyncExecutor");
System.out.println("active=" + executor.getActiveCount() + ", queue=" + executor.getThreadPoolExecutor().getQueue().size());
```

证据是 active=20，queue=80，说明核心线程和最大线程都已打满，队列堆积。

根因是慢逻辑耗时 3 秒，20 个线程每秒只能处理约 6.7 个任务，100 并发自然排队。

修复方式是调大线程池或对慢逻辑本身做缓存。

**错误尝试：** 一开始把 Tomcat 最大线程数从 200 调到 500，压测时线程池依然被打满，而且 CPU 上下文切换增加，普通接口响应反而更慢。

这说明不解决慢逻辑占用线程的问题，光加线程是饮鸩止渴。

> 超时如刀断前缘，
> 队列如山压两边。
> 错把线程加五百，
> 切换更比等待艰。

# 07、优化

```text
V1：Callable 无超时无断连处理
证据：客户端断开后任务继续执行，超时后异常未捕获
V2：WebAsyncTask 增加超时回调、异常处理、断连取消
```

V1 的 Callable 无法设置单个任务的超时时间，也无法在客户端断开时取消任务。V2 改用 WebAsyncTask，它支持超时回调、异常回调和任务取消。

```java
@GetMapping("/{petId}/health")
public WebAsyncTask<HealthReport> generateHealthReport(@PathVariable Long petId) {
    Callable<HealthReport> callable = () -> {
        Thread.sleep(3000);
        return new HealthReport(petId, "正常", "2025-01-01");
    };

    WebAsyncTask<HealthReport> asyncTask = new WebAsyncTask<>(5000, callable);
    asyncTask.onTimeout(() -> {
        System.out.println("任务超时，返回兜底报告");
        return new HealthReport(petId, "超时兜底", "2025-01-01");
    });
    asyncTask.onError(() -> {
        System.out.println("任务异常，返回错误报告");
        return new HealthReport(petId, "异常兜底", "2025-01-01");
    });
    return asyncTask;
}
```

同时配置 AsyncTaskExecutor 的拒绝策略，避免队列满时静默丢弃：

```java
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
```

这样当业务线程池满时，任务会由提交线程执行，虽然会阻塞一个 Servlet 线程，但不会丢失请求。

> 超时兜底不空手，
> 异常回执也温柔。
> 队列满时莫丢弃，
> 借线一用解近忧。

# 08、演进

```text
V2：WebAsyncTask 超时与异常兜底
能力：DeferredResult 支持外部事件驱动，SSE 支持流式推送
遗留：客户端断开检测依赖容器，跨服务事件需要消息中间件
```

V2 解决了超时和异常，但 WebAsyncTask 仍然是“请求进来就执行”的模式。

如果报告需要等待外部检测系统回调，DeferredResult 更合适，它允许在任意线程里 setResult 完成响应。

```java
@GetMapping("/{petId}/health/deferred")
public DeferredResult<HealthReport> generateDeferred(@PathVariable Long petId) {
    DeferredResult<HealthReport> result = new DeferredResult<>(8000L);
    result.onTimeout(() -> result.setResult(new HealthReport(petId, "外部系统超时", "2025-01-01")));
    // 模拟外部系统异步回调
    CompletableFuture.supplyAsync(() -> {
        try { Thread.sleep(3000); } catch (InterruptedException e) { }
        return new HealthReport(petId, "外部系统正常", "2025-01-01");
    }).thenAccept(result::setResult);
    return result;
}
```

如果报告生成过程可以分阶段推送，比如先推疫苗记录、再推体重曲线，SSE 是更好的选择：

```java
@GetMapping(value = "/{petId}/health/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter streamHealth(@PathVariable Long petId) {
    SseEmitter emitter = new SseEmitter(10000L);
    Executors.newSingleThreadExecutor().execute(() -> {
        try {
            emitter.send("疫苗记录：齐全");
            Thread.sleep(1000);
            emitter.send("体重曲线：正常");
            Thread.sleep(1000);
            emitter.send("报告完成");
            emitter.complete();
        } catch (Exception e) {
            emitter.completeWithError(e);
        }
    });
    return emitter;
}
```

用 V1 同一组请求验证：50 并发下，同步接口 Tomcat 线程占用 50 个持续 3 秒；WebAsyncTask 接口 Tomcat 线程占用峰值只有 5 个，业务线程池占用 50 个。

> 外部回调 Deferred 等，
> 流式推送 SSE 行。
> 同组请求前后比，
> 一线释放五线轻。

# 09、洞见

```text
从现象到判断：线程名变化 → 释放时机 → 重新 dispatch → 异步边界
```

## 异步化只转移等待，不消除等待
```text
同步：Servlet 线程等待慢逻辑
异步：业务线程等待慢逻辑
结论：总等待时间不变，变的是等待发生在哪个线程池
```

反直觉判断：很多人以为异步化能让接口变快，实际上响应时间几乎不变，甚至因为线程切换略增。异步化的价值是让 Servlet 线程池不被慢请求占满，保护普通请求的可用性。

## 重新 dispatch 是异步最容易忽略的环节
```text
任务完成 → 重新 dispatch → 再次占用 Servlet 线程 → 写响应
```

反直觉判断：异步不是完全不用 Servlet 线程，而是把“长时间占用”变成“两次短时间占用”。如果写响应本身很慢，比如返回超大 JSON，异步化的收益会大打折扣。

## 超时和断连是异步的必修课
```text
客户端断开 → 服务端不知道 → 任务继续执行 → 资源浪费
```

同步模型下客户端断开，Servlet 线程通常会在写响应时发现异常。

异步模型下任务在业务线程池执行，客户端断开不会自动取消任务，必须通过 DeferredResult 或 WebAsyncTask 的回调来处理。

## 线程池隔离是异步化的前提
```text
Servlet 线程池：接收请求、写响应
业务线程池：执行慢逻辑
两个池必须独立配置
```

如果业务线程池和 Servlet 线程池共用，异步化就失去了意义。业务线程池的队列、拒绝策略、线程数都要根据慢逻辑的耗时和并发量单独测算。

> 异步非快是移山，
> 一线两借莫等闲。
> 断连超时须早断，
> 两池隔离方得安。

# 10、系统落地

```text
入口：Petclinic 前端报告页 → 服务：ReportController → 本模块：MVC Async 异步化 → 存储：宠物档案库 → 未实现：报告缓存与消息队列
```

原来 Petclinic 只有同步的宠物档案查询，本篇增加了健康报告异步生成能力，支持 Callable、WebAsyncTask、DeferredResult 和 SSE 四种模式。

现在系统能做的：慢报告请求不再阻塞 Tomcat 工作线程，超时和异常有兜底，外部系统回调可以用 DeferredResult 等待，分阶段报告可以用 SSE 推送。

下一篇缺的是报告结果缓存和跨服务消息队列。当报告生成完成后，如果能把结果缓存到 Redis，相同宠物短时间内重复请求可以直接返回，不需要重新执行慢逻辑。

官方文档可参考 Spring Framework 官方文档主页 https://spring.io/projects/spring-framework 和 GitHub 仓库 https://gith

ub.com/spring-projects/spring-framework 。

> 入口前端点报告，
> 服务异步接慢招。
> 存储档案仍如旧，
> 缓存队列待明朝。

# 11、小结

```text
三问三答：为什么拖垮 → 线程池被慢请求占满
选哪种异步 → 按场景选 Callable/WebAsyncTask/DeferredResult/SSE
选错后果 → 线程池泄漏或结果无法返回
```

为什么同步慢接口会拖垮整个 Tomcat 线程池？因为每个慢请求都占用一个 Servlet 线程等待，线程池耗尽后普通请求无法进入。

应该用哪种异步模型？简单慢逻辑用 Callable 或 WebAsyncTask，需要外部回调用 DeferredResult，需要流式推送用 SSE。

选错会怎样？忽略超时会导致任务无限占用业务线程，忽略客户端断开会导致资源浪费，线程池配置不当会导致队列堆积或任务丢失。

当前状态：V2 已支持超时兜底和异常处理，DeferredResult 与 SSE 已跑通，下一步需要补缓存和消息队列。

> 一问线程何所困，
> 二问异步哪般选。
> 三问错路何所失，
> 答罢方知行路难。

# 12、作业

```text
理解→实战→排障→架构判断
```

## 理解题：MVC Async 为什么不能让慢 SQL 变快？

MVC Async 只是把等待从 Servlet 线程转移到业务线程池，慢 SQL 的执行时间由数据库决定，不会因为异步化而缩短。

异步化的收益是释放 Servlet 线程，让 Tomcat 能接收更多请求，而不是提升单个请求的响应速度。

## 实战题：用 Debug 断点观察 Callable 模式下线程名的变化，记录释放和重新 dispatch 的时机。

在 Controller 返回 Callable 处打断点，观察 http-nio-8080-exec 线程提交任务后立即返回。

在 Callable 内部打断点，观察 pet-async-1 线程执行慢逻辑。

在响应写回处打断点，观察新的 http-nio-8080-exec 线程重新进入 DispatcherServlet。

记录三个断点的线程名和时间戳，验证释放与重新 dispatch 的完整链路。

## 排障题：客户端断开后服务端任务仍在执行，如何定位并修复？

用 curl 设置短超时发起请求，服务端日志观察任务是否继续执行。

在 DeferredResult 上注册 onCompletion 回调，打印客户端断开事件。

修复方式是在 onCompletion 或 onError 回调中取消底层任务，比如调用 Future.cancel(true)，避免资源浪费。

## 架构判断题：业务线程池和 Servlet 线程池共用同一个池，异步化还有意义吗？

没有意义。如果两个池共用，慢任务依然会占满所有线程，Servlet 线程无法及时释放，异步化形同虚设。

必须将业务线程池独立配置，并根据慢逻辑的耗时和并发量设置核心线程数、最大线程数、队列容量和拒绝策略。

> 理解如灯照暗路，
> 实战如杖探深浅。
> 排障如医诊脉象，
> 架构如匠量方圆。

# 13、升华

```text
工程结论：MVC Async 优化的是线程占用结构，不是业务执行速度
```

MVC Async 的工程价值在于把“长时间占用 Servlet 线程”变成“短时间借用 Servlet 线程”，让 Web 容器在慢请求占比升高时依然能保持普通请求的可用性。

它不是银弹，慢 SQL 要优化 SQL，CPU 密集要优化算法，异步化只解决线程等待问题。判断是否异步化的标准是：慢逻辑是否以 IO 等待为主，以及 Servlet 线程池是否已经成为瓶颈。

下一篇将引入报告结果缓存，用 Redis 把已生成的报告缓存起来，相同请求直接返回，进一步减少慢逻辑的执行次数。

> 异步非为快马鞭，
> 只教一线不空眠。
> 慢工仍须慢工解，
> 缓存接力下一篇。

**系列项目：** Petclinic 宠物医疗 SaaS 系统，服务宠物诊所与宠物主人

**已完成：** 同步宠物健康报告接口，支持多源聚合生成

**本篇：** 新增 MVC Async 异步化能力，支持 Callable、WebAsyncTask、DeferredResult、SSE，含超时、异常、断连处理

**下一篇：** 报告结果缓存与跨服务消息队列，减少慢逻辑重复执行

Petclinic 原本的宠物健康报告接口是同步执行，请求进来后从数据库拉取宠物档案、疫苗记录、体重曲线，再汇总成报告。

《SpringMVC7实战》第16招 Async MVC怎么释放Servlet线程

以宠物健康报告慢接口为线，拆解 Callable、DeferredResult、WebAsyncTask 与 SSE 的线程释放、超时、异常和断连处理，用 De

架构师

人工智能

MVCAsync异步化改造实战：从同步阻塞到Servlet线程释放，详解Callable、WebAsyncTask、DeferredResult与SSE四种异步模型选型对比。通过Petclinic宠物报告接口案例，展示超时兜底、客户端断连处理、线程池隔离等关键配置，有效解决Tomcat线程耗尽问题，提升高并发场景下的系统稳定性与响应能力。

消息队列

代码解释

中间件

数据库

容器

GitHub

Redis

SaaS

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MVCAsync异步化改造实战：从同步阻塞到Servlet线程释放，详解Callable、WebAsyncTask、DeferredResult与SSE四种异步模型选型对比。通过Petclinic宠物报告接口案例，展示超时兜底、客户端断连处理、线程池隔离等关键配置，有效解决Tomcat线程耗尽问题，提升高并发场景下的系...

《SpringMVC7实战》第16招 Async MVC怎么释放Servlet线程-腾讯云开发者社区-腾讯云

《SpringMVC7实战》第16招 Async MVC怎么释放Servlet线程

《SpringMVC7实战》第16招 Async MVC怎么释放Servlet线程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐