Decade
Web服务器高并发技术深度解析：事件循环 vs 线程池模型
Zhongjun Qiu 元婴开发者
  2025-12-30 00:00:00   2026-02-02 23:50:40    5.5k Words  20 Mins  

核心对比

事件循环和线程池是两种本质不同的并发模型。事件循环用”时间分片”在一个线程上同时处理数万连接，资源占用极低；线程池用”真并行”让每个请求独占资源，简单但开销巨大。本文将深入解析这两种模型的底层原理、优缺点对比，以及在什么场景下选择哪种架构。

一、Uvicorn 的异步实现原理

Uvicorn 是一个 ASGI（Asynchronous Server Gateway Interface）服务器，它的核心异步能力完全基于 Python 的 asyncio 生态：

1.1 核心组件

  • 事件循环：Uvicorn 使用 asyncio 的事件循环来驱动整个服务器。默认情况下，它会将标准库的 asyncio 事件循环替换为 uvloop（一个用 Cython 实现的、更高效的事件循环），显著提升性能。

  • HTTP 解析：使用 httptools（基于 llhttp 的高速 HTTP 协议解析器）来快速解析传入的请求，而不阻塞事件循环。

  • 连接管理：每个传入的 TCP 连接都被包装成 asyncio 的传输（transport）和协议（protocol）对象。服务器在单个线程（单个事件循环）内并发处理数千个连接，通过非阻塞 I/O 和协程调度实现高并发。

  • Worker 模型：

    • 单 worker 时：纯异步，单进程单线程，利用 asyncio 并发处理所有请求
    • 多 worker 时（uvicorn --workers N）：启动多个进程，每个进程独立运行一个事件循环，实现多核利用

1.2 本质特点

Uvicorn 的异步是”原生”的：它本身就是为异步应用设计的服务器，不依赖线程或多进程来实现并发（除非你手动开启多 worker）。这与传统的多线程服务器形成鲜明对比。

二、FastAPI 框架与异步的关系

2.1 核心问题：框架是否完全不需要关心异步/协程？

答案是：可以不关心，但如果你想真正发挥异步的优势，就必须关心。

FastAPI 基于 Starlette，而 Starlette 是纯 ASGI 框架。你可以写两种路由：

1
2
3
4
5
6
7
8
9
# 异步路由：真正的异步端点
@app.get("/")
async def read_root():
    return {"message": "Hello World"}

# 同步路由：普通函数
@app.get("/")
def read_root():
    return {"message": "Hello World"}

2.2 运行机制差异

  • async def 路由：真正的异步端点，直接在事件循环中运行
  • def 路由（普通同步函数）：FastAPI/Uvicorn 会自动把它丢到线程池（默认 concurrent.futures.ThreadPoolExecutor）中执行，避免阻塞主事件循环

2.3 何时可以”不关心”

如果你的应用主要是 CPU-bound 或同步阻塞操作（比如同步数据库查询、同步 HTTP 调用），用同步路由也没问题，Uvicorn 会用线程池帮你处理，不会让整个服务器卡死。对于轻量级的 API，甚至很多生产环境一开始都用同步写法，性能也足够。

2.4 想获得最佳性能，必须主动写异步代码

只有当路由是 async def，并且内部使用异步库时，才能真正实现”零线程、高并发”的异步 I/O。

典型异步库选择： - 数据库：asyncpg（PostgreSQL）、databases、SQLAlchemy 2.0 async 等异步驱动 - HTTP 客户端：httpx 或 aiohttp - 文件 I/O：aiofiles

警告：如果你在 async def 路由里调用了阻塞的同步代码（比如 requests.get()），它仍然会阻塞整个事件循环，导致并发度大幅下降。

2.5 形象类比

Uvicorn 是”底盘”，FastAPI 是”车身”，想跑得快，还得装”好发动机”（异步代码）。

三、与 Java Spring 生态的类比对比

Python 侧（FastAPI + Uvicorn） Java Spring 侧对应技术 类比要点
Uvicorn（ASGI 服务器） Netty（或 Reactor Netty） 两者都是底层高性能、事件驱动、非阻塞 I/O 的网络服务器
FastAPI / Starlette（ASGI 框架） Spring WebFlux（响应式 Web 栈） 两者都是为异步/非阻塞设计的现代 Web 框架
FastAPI 中的同步路由（def 普通函数） Spring MVC（传统阻塞式） 两者都”向下兼容”同步代码，同步代码会被丢到线程池执行
ASGI Reactive Streams 两者都是框架与服务器之间的”契约”
传统同步框架（Flask + Gunicorn） Spring MVC + Tomcat 经典的阻塞式、多线程/多进程模型

关键行为类比

纯异步路径（最高性能） - FastAPI：async def 路由 + 异步库（asyncpg、httpx）+ Uvicorn - Spring：Mono/Flux 返回类型 + 响应式驱动（R2DBC、WebClient）+ Netty - 两者都在单线程事件循环上实现高并发，无线程切换开销

混合/同步路径（最常见起步方式） - FastAPI：同步路由 + 同步库（SQLAlchemy sync、requests）+ Uvicorn（自动线程池） - Spring：Spring MVC Controller + 阻塞 JDBC/HttpClient + Tomcat（线程池） - 开发最简单，框架自动处理阻塞不卡死服务器

四、SpringBoot 阻塞式为何能支持高并发？

很多人认为阻塞式就是低并发，这是误解。Spring Boot + Spring MVC 虽然是阻塞式模型，但通过多种优化手段，仍然能轻松扛住数千甚至上万的 QPS。

4.1 Spring Boot + Spring MVC 的默认运行模型

  • 核心机制：基于 Java Servlet API，嵌入式服务器默认是 Tomcat
  • 线程模型：经典的 “线程池 + 线程 per request”
    • Tomcat 维护一个线程池（默认最大 200 个线程，可配置到上千）
    • 每个 HTTP 请求到来时，从线程池取一个线程执行整个请求
  • 连接层优化：Tomcat 的连接器支持 NIO（Non-blocking I/O） 或 APR（native） 模式

4.2 为什么阻塞式还能支持高并发？

  1. 线程池规模可调：Tomcat 默认 maxThreads=200，但生产环境常配置到 800~2000 甚至更高

  2. I/O 等待时间通常很短：现代数据库（如 MySQL + 连接池）、缓存（Redis）、外部 API 的响应往往在 10~100ms 内

  3. 其他优化手段：

    • 连接池：Druid/HikariCP 管理数据库连接
    • 缓存：Redis、Caffeine 减少数据库压力
    • 异步任务：@Async、消息队列把耗时操作移出请求线程
    • 水平扩展：部署多个 Spring Boot 实例 + Nginx/Envoy 负载均衡

4.3 Spring MVC vs Spring WebFlux 对比

方面 Spring MVC（阻塞式） Spring WebFlux（非阻塞式）
服务器默认 Tomcat（线程池） Netty（事件循环）
线程模型 多线程（数百~数千线程） 少量线程（通常等于 CPU
高（靠线程数扩展） 更高（单线程处理数万连接）
资源占用 较高（每个请求占一个线程栈 ~1MB） 极低（协程式，内存占用小）
开发复杂度 低（同步代码，生态最丰富） 高（需要响应式编程、Mono/Flux）
适用场景 绝大多数传统业务、CRUD、内部系统 极高并发、长连接、流式处理

4.4 为什么很多项目仍然选择 Spring MVC？

  • 开发效率高：同步代码直观、调试简单、生态成熟
  • 性能足够：99% 的项目不需要 WebFlux 那种极致并发
  • 迁移成本高：从 MVC 切换到 WebFlux 需要重写大量代码

Spring 官方明确表示：除非有明确的高并发或背压需求，否则优先推荐 Spring MVC。

五、事件循环 vs 线程池：两种并发模型的深度解析

5.1 核心机制差异

事件循环（非阻塞/异步模型） - 单线程（或少量线程）运行一个循环，不断轮询事件（I/O 就绪、定时器等） - 当请求涉及 I/O 时，不会阻塞线程，而是注册回调/协程，事件循环在等待期间切换去处理其他请求

线程池（阻塞/同步模型） - 维护一个线程池（数百到数千线程） - 每个请求分配一个专用线程，线程从头到尾处理该请求 - 如果涉及 I/O，线程会阻塞等待（闲置），直到 I/O 完成才能继续

5.2 性能对比

方面 事件循环（Event Loop） 线程池（Thread Pool）
最大并发连接 极高（单线程可处理数万~数十万连接） 中等（受线程数限制，通常数百~数千）
吞吐量 (QPS) I/O 密集场景下更高（无上下文切换开销） 足够高，但线程多时上下文切换开销大
延迟 更低（快速切换任务） 稍高（线程调度开销）
资源占用 低（无线程栈开销，内存/CPU 高效） 高（每个线程栈 ~1MB，上下文切换耗 CPU）
扩展方式 单进程多核难（需多进程 + 负载均衡） 易多核（线程池天然利用多核）

5.3 优缺点对比

事件循环的优势 - 资源效率高：适合高并发、低负载的 I/O 密集型应用 - 可预测性强：无线程竞争问题（锁少）

事件循环的劣势 - CPU 密集任务会阻塞整个循环（需手动卸载到线程池） - 编程模型复杂（需 async/await、回调、Mono/Flux）

线程池的优势

  • 开发简单：同步代码直观，生态成熟
  • 天然支持 CPU 密集任务（多线程并行计算）

线程池的劣势 - 线程开销大，高并发下内存/CPU 压力大 - 线程池耗尽时请求排队或拒绝

5.4 一句话总结

  • 事件循环：用”时间分片”在一个线程上”假装”同时处理很多事，高效但要求代码非阻塞
  • 线程池：用”真并行”多线程每个请求独占资源，简单但开销大

六、Spring MVC 的异步支持机制

6.1 异步实现方式

Spring MVC 基于 Servlet 3.0+ 的异步特性，允许你在不阻塞容器线程的情况下处理耗时操作：

1. Controller 返回 Callable / WebAsyncTask

1
2
3
4
5
6
7
8
@GetMapping("/async")
public Callable<String> asyncEndpoint() {
    return () -> {
        // 这里执行耗时操作（如外部 API 调用、复杂计算）
        Thread.sleep(5000); // 模拟耗时
        return "done";
    };
}

线程行为： - 请求到达时，Tomcat 的 worker 线程执行到返回 Callable - Spring 将 Callable 提交到 TaskExecutor 执行 - 容器线程立即释放，返回 Tomcat 线程池 - 耗时任务在另一个线程中执行，完成后结果写回响应

2. 使用 DeferredResult / WebAsyncTask

1
2
3
4
5
6
7
8
9
@GetMapping("/deferred")
public DeferredResult<String> deferredEndpoint() {
    DeferredResult<String> result = new DeferredResult<>();
    executor.submit(() -> {
        // 耗时操作
        result.setResult("done");
    });
    return result;
}

3. @Async 在 Service 层

1
2
3
4
5
6
7
8
@Service
public class MyService {
    @Async  // 需要 @EnableAsync 开启
    public CompletableFuture<Void> longTask() {
        // 耗时操作
        return CompletableFuture.completedFuture(null);
    }
}

6.2 异步的价值

是的，会释放线程

Tomcat 的 worker 线程在异步任务提交后立即返回池中。这大大提高了并发能力：原本一个耗时 5 秒的请求会独占线程 5 秒，现在只占用几毫秒。

6.3 实际数字对比

假设： - Tomcat maxThreads=200 - 每个请求有 5 秒耗时 I/O 操作 - 请求平均处理时间（不含耗时）：100ms

模式 最大稳定并发（理论） 说明
纯同步（全阻塞） ~200 每个请求独占一个容器线程 5 秒多
异步（释放容器线程） 几千甚至上万 容器线程快速释放，复用率极高
纯非阻塞（WebFlux） 更高（数万） 全程无阻塞，线程几乎不闲置

6.4 局限性

这种异步机制的本质是“线程池分层”：把珍贵的”前端线程”保护起来，让它们只做轻量活，把重活丢给”后端工人”。

但仍有局限： - 后端线程还是会被阻塞占用，如果 TaskExecutor 也耗尽，任务会排队 - 如果耗时任务超级多/超级长，仍然需要进一步优化 - 资源占用比纯事件循环高（两个线程池 vs 一个事件循环）

七、阻塞与非阻塞的本质区别

7.1 为什么事件循环模型必须使用非阻塞库？

在事件循环模型（如 Spring WebFlux + Netty、FastAPI async + Uvicorn）中，整个服务器的核心是单线程（或少量线程）的事件循环。

如果任何 I/O 操作是阻塞式的，它会直接阻塞整个事件循环线程，导致： - 整个服务器卡顿：在等待 I/O 完成期间，事件循环无法切换到其他请求 - 并发度崩盘：原本能处理数万连接的系统，瞬间降到只能处理一个请求 - 雪崩风险：高并发下，系统响应变慢、超时、拒绝服务

7.2 阻塞 vs 非阻塞在事件循环中的区别

方面 阻塞式 I/O（同步库，如 JdbcTemplate、requests） 非阻塞式 I/O（WebClient、R2DBC、httpx、asyncpg）
线程行为 当前线程立即挂起等待（闲置）。在事件循环中，这就是阻塞整个循环 线程不等待，立即返回”未来结果”。事件循环注册回调，继续处理其他任务
等待期间 线程闲置，无法做任何事 → 整个服务器停转 事件循环切换到其他请求/协程 → 高并发持续
并发效果 差：一个阻塞操作卡住所有请求 优：单线程处理数万请求，线程利用率接近 100%
示例后果 一个慢数据库查询（5 秒）→ 所有客户端都等 5 秒+ 一个慢查询只影响自身，其他请求正常处理

7.3 在”线程池 + 异步”实现中的区别

方面 阻塞式 I/O（常见，如 RestTemplate、JDBC） 非阻塞式 I/O（WebClient 等，可用但非必须）
线程行为 阻塞操作占用后端线程池的一个线程（TaskExecutor）。容器线程已释放，不影响前端 同事件循环：不阻塞任何线程，但收益有限（因为已有线程池）
等待期间 该后端线程闲置，但其他线程继续工作 → 系统整体正常 后端线程不闲置，利用率更高
并发效果 好：只影响一个线程，后端池可扩容（数百线程） 更好：但在多线程环境中提升有限
为什么阻塞库可用 阻塞只影响”后端工人线程”，前端容器线程已保护好 非必须，但推荐用于极致优化

7.4 形象比喻

事件循环模型： - 阻塞：厨师（事件循环线程）做菜时必须盯着锅等水开 → 只能服务一个客人 - 非阻塞：厨师下指令后去服务其他客人，水开时闹钟响再回来 → 一个厨师服务几十个客人

线程池模型： - 阻塞：一个工人盯着锅等水开（闲置），但其他工人继续干活，前台继续接待客人 - 非阻塞：工人下指令就去干别的事，更高效，但系统已有多个工人，差距不如事件循环大

八、协程 vs 线程：用户态与内核态的较量

8.1 基本定义与特性对比

方面 协程 (Coroutines) 线程 (Threads)
调度方式 用户态调度（由语言运行时/事件循环控制） 内核态调度（由 OS 控制）
重量级 轻量（栈空间小，通常几 KB） 重量（默认栈 1MB+，创建/切换开销大）
数量规模 极多（单线程可调度数万~数十万个协程） 有限（数百~数千，受内存/CPU 限制）
切换开销 极低（用户态，直接跳转） 高（涉及内核上下文切换、TLB 失效等）
阻塞行为 协程”挂起”（yield/await）时不阻塞底层线程 线程阻塞时，整个线程闲置（OS 切换其他线程）
典型实现 Python async/await、Go goroutine、Java 虚拟线程（Loom） Java Thread、Python threading、OS pthread

8.2 核心区别：用户态 vs 内核态调度

协程是用户态的概念 - 调度者：由程序运行时（如 Python asyncio、Go runtime、Java Loom）控制 - 切换开销：极低（几微秒）：直接保存/恢复寄存器和栈指针 - 内核可见性：内核完全看不到协程（只看到承载它们的线程）

线程是内核态的概念 - 调度者：由操作系统内核（Linux kernel、Windows scheduler）控制 - 切换开销：高（几十微秒~毫秒）：涉及内核陷阱、上下文切换、缓存失效 - 内核可见性：内核直接管理每个线程（调度、资源分配）

8.3 在两种并发模型中的角色

事件循环模型（协程主导） - 协程是主角，线程是”幕后支撑” - 高并发靠协程堆叠：资源占用极低，适合 I/O 密集 - 一个内核线程运行事件循环，调度成千上万协程 - 协程挂起时：用户态切换 → 底层线程继续跑其他协程

线程池 + 异步模型（线程主导） - 线程是唯一主角，协程不存在或很少 - 高并发靠线程堆叠：每个请求/任务占一个线程，资源占用高 - 部分异步只是”线程分层”，本质仍是多线程阻塞模型的优化

8.4 总结

协程是用户态的”伪并发”（协作式、轻量、高效），用来在少量内核线程上模拟大量并发；线程是内核态的”真并发”（抢占式、重量、真实并行）。内核永远只认识线程，协程只是聪明地在用户空间”偷懒”分工，让线程利用率更高。

九、实战场景：协程何时优于线程？

9.1 经典场景：高并发 I/O 密集型 Web 服务器

场景描述

想象你开发一个实时股票报价服务： - 服务器需要同时服务 50,000 个客户端连接 - 每个连接每秒可能发起一个请求：查询外部数据源（网络 I/O，平均延迟 50~200ms） - 请求主要是 I/O 等待（非 CPU 计算）

用传统线程模型的表现 - 内存爆炸：每个线程默认栈空间 1MB，50,000 线程 ≈ 50GB 内存 - 上下文切换开销：OS 频繁切换线程，CPU 利用率低，系统抖动大 - 实际极限：一台中等服务器（32 核 64GB 内存）最多稳定处理几千~一万并发 - 扩展成本：需多实例 + 负载均衡，部署复杂，资源浪费

用协程模型的表现 - 内存极低：每个协程栈空间仅几 KB（Go goroutine 初始 2KB），50,000 协程 ≈ 几百 MB 内存 - 切换高效：协程在用户态协作切换（I/O 等待时主动 yield），无内核介入，开销微秒级 - 实际极限：单机轻松处理 10 万~百万并发 - 资源效率：一台服务器顶得上传统模型的 10~100 台

9.2 量化对比（基于真实基准测试）

指标 线程模型（Java Servlet + Tomcat） 协程模型（Go / Vert.x / FastAPI async）
单机最大并发连接 ~20,000（受内存/线程限制） ~1,000,000+
内存占用（10万并发） ~100GB+（不可行） ~15GB
平均延迟（高负载下） 高（线程切换 + 排队） 低（高效复用）
CPU 利用率 中低（大量闲置等待） 高（持续调度）

9.3 为什么协程”偷懒”分工在这里胜出？

  • 协程让一个内核线程”假装”同时干数万件事：I/O 等待时不闲置线程，而是用户态快速切换协程
  • 内核只看到少数忙碌线程（高效利用 CPU 时间片），而传统线程模型让内核管理数万闲置线程（浪费）
  • 真实案例：Discord（聊天服务）用 Go（协程）单机处理百万连接；许多 CDN/网关用 Node.js/Go 而非 Java 线程池

9.4 适用场景总结

优先事件循环（协程） - 高并发 I/O（如实时推送、大量 API 调用、WebSocket 长连接） - 资源受限环境（云服务器、容器）

优先线程池 - 混合负载（有 CPU 计算） - 快速开发、遗留系统 - 并发需求不高（< 数千 QPS）

十、总结与选型建议

10.1 核心要点回顾

  1. Uvicorn 提供了完整的异步运行环境（事件循环 + 非阻塞服务器）
  2. FastAPI 这类现代 ASGI 框架让你可以”无痛”运行同步代码，但真正的异步高性能需要你在业务层主动使用 async/await 和异步生态库
  3. 事件循环模型 vs 线程池模型：
    • 事件循环：用”时间分片”在一个线程上”假装”同时处理很多事，高效但要求代码非阻塞
    • 线程池：用”真并行”多线程每个请求独占资源，简单但开销大
  4. 阻塞 vs 非阻塞：
    • 事件循环模型：必须非阻塞，否则整个单线程崩了——这是”生死线”
    • 线程池 + 异步模型：阻塞库没问题（只堵一个线程），非阻塞库是锦上添花
  5. 协程 vs 线程：
    • 协程是用户态的”伪并发”（协作式、轻量、高效）
    • 线程是内核态的”真并发”（抢占式、重量、真实并行）

10.2 选型建议

选择事件循环 + 非阻塞模型（FastAPI async、WebFlux） - 你的应用对并发要求极高（数万~数十万并发） - 主要是 I/O 密集型任务（大量数据库/外部 API 调用、WebSocket 长连接） - 资源受限环境（云服务器、容器） - 你愿意学习异步/响应式编程模型

选择线程池 + 异步模型（Spring MVC） - 你的应用对并发要求不高（< 数千 QPS） - 有 CPU 计算任务或混合负载 - 开发速度优先、代码遗留多 - 生态兼容性要求高（很多库只提供同步版本）

混合使用

  • 在事件循环模型中，用线程池处理 CPU 密集任务
  • 在线程池模型中，用异步编程释放容器线程，提升并发

10.3 最终建议

现代系统往往混合使用两种模型。如果不确定，从简单的线程池模型开始（Spring MVC、FastAPI 同步路由），在遇到真正的性能瓶颈时再考虑迁移到纯事件循环模型。记住：过早优化是万恶之源。

对于大多数企业内部系统、普通 API 服务，Spring MVC + 异步（Callable/@Async）或 FastAPI（同步路由）已经足够了。只有当你真正需要处理数万并发、大量长连接或极致资源效率时，才需要全面拥抱事件循环 + 非阻塞模型。

本文整理自与 AI 的技术对话，深入探讨了 Web 服务器异步实现的方方面面。如有疑问或需要补充，欢迎讨论。

Web服务器高并发技术深度解析：事件循环 vs 线程池模型
2025/12/30/uvicorn-fastapi-async-deep-dive/
Author
Zhongjun Qiu
Published
2025-12-30 00:00
License
 REWARD AUTHOR
 Comments
Comment plugin failed to load
Loading comment plugin
  1. 核心对比
  2. 一、Uvicorn 的异步实现原理
    1. 1.1 核心组件
    2. 1.2 本质特点
  3. 二、FastAPI 框架与异步的关系
    1. 2.1 核心问题：框架是否完全不需要关心异步/协程？
    2. 2.2 运行机制差异
    3. 2.3 何时可以”不关心”
    4. 2.4 想获得最佳性能，必须主动写异步代码
    5. 2.5 形象类比
  4. 三、与 Java Spring 生态的类比对比
    1. 关键行为类比
  5. 四、SpringBoot 阻塞式为何能支持高并发？
    1. 4.1 Spring Boot + Spring MVC 的默认运行模型
    2. 4.2 为什么阻塞式还能支持高并发？
    3. 4.3 Spring MVC vs Spring WebFlux 对比
    4. 4.4 为什么很多项目仍然选择 Spring MVC？
  6. 五、事件循环 vs 线程池：两种并发模型的深度解析
    1. 5.1 核心机制差异
    2. 5.2 性能对比
    3. 5.3 优缺点对比
    4. 5.4 一句话总结
  7. 六、Spring MVC 的异步支持机制
    1. 6.1 异步实现方式
    2. 6.2 异步的价值
    3. 6.3 实际数字对比
    4. 6.4 局限性
  8. 七、阻塞与非阻塞的本质区别
    1. 7.1 为什么事件循环模型必须使用非阻塞库？
    2. 7.2 阻塞 vs 非阻塞在事件循环中的区别
    3. 7.3 在”线程池 + 异步”实现中的区别
    4. 7.4 形象比喻
  9. 八、协程 vs 线程：用户态与内核态的较量
    1. 8.1 基本定义与特性对比
    2. 8.2 核心区别：用户态 vs 内核态调度
    3. 8.3 在两种并发模型中的角色
    4. 8.4 总结
  10. 九、实战场景：协程何时优于线程？
    1. 9.1 经典场景：高并发 I/O 密集型 Web 服务器
    2. 9.2 量化对比（基于真实基准测试）
    3. 9.3 为什么协程”偷懒”分工在这里胜出？
    4. 9.4 适用场景总结
  11. 十、总结与选型建议
    1. 10.1 核心要点回顾
    2. 10.2 选型建议
    3. 10.3 最终建议
  1. 核心对比
  2. 一、Uvicorn 的异步实现原理
    1. 1.1 核心组件
    2. 1.2 本质特点
  3. 二、FastAPI 框架与异步的关系
    1. 2.1 核心问题：框架是否完全不需要关心异步/协程？
    2. 2.2 运行机制差异
    3. 2.3 何时可以”不关心”
    4. 2.4 想获得最佳性能，必须主动写异步代码
    5. 2.5 形象类比
  4. 三、与 Java Spring 生态的类比对比
    1. 关键行为类比
  5. 四、SpringBoot 阻塞式为何能支持高并发？
    1. 4.1 Spring Boot + Spring MVC 的默认运行模型
    2. 4.2 为什么阻塞式还能支持高并发？
    3. 4.3 Spring MVC vs Spring WebFlux 对比
    4. 4.4 为什么很多项目仍然选择 Spring MVC？
  6. 五、事件循环 vs 线程池：两种并发模型的深度解析
    1. 5.1 核心机制差异
    2. 5.2 性能对比
    3. 5.3 优缺点对比
    4. 5.4 一句话总结
  7. 六、Spring MVC 的异步支持机制
    1. 6.1 异步实现方式
    2. 6.2 异步的价值
    3. 6.3 实际数字对比
    4. 6.4 局限性
  8. 七、阻塞与非阻塞的本质区别
    1. 7.1 为什么事件循环模型必须使用非阻塞库？
    2. 7.2 阻塞 vs 非阻塞在事件循环中的区别
    3. 7.3 在”线程池 + 异步”实现中的区别
    4. 7.4 形象比喻
  9. 八、协程 vs 线程：用户态与内核态的较量
    1. 8.1 基本定义与特性对比
    2. 8.2 核心区别：用户态 vs 内核态调度
    3. 8.3 在两种并发模型中的角色
    4. 8.4 总结
  10. 九、实战场景：协程何时优于线程？
    1. 9.1 经典场景：高并发 I/O 密集型 Web 服务器
    2. 9.2 量化对比（基于真实基准测试）
    3. 9.3 为什么协程”偷懒”分工在这里胜出？
    4. 9.4 适用场景总结
  11. 十、总结与选型建议
    1. 10.1 核心要点回顾
    2. 10.2 选型建议
    3. 10.3 最终建议