Webflux

Spring WebFlux 是 Spring 5（2017）引入的响应式 Web 框架，与基于 Servlet 的 Spring MVC 并列。Boot 总览见 Spring Boot；若只需提升并发能力而不改编程模型，可先看 Java Virtual Threads。 解决的问题 传统 Spring MVC 基于 Servlet 模型，每个请求占用一个线程，调用数据库或外部 API 时线程阻塞等待： 请求进来 → 分配线程 → 调用数据库（等待 100ms，线程阻塞）→ 调用外部 API（等待 200ms，线程阻塞）→ 返回 Tomcat 默认线程池约 200 个线程，高并发下线程池耗尽，后续请求排队。 Spring WebFlux 引入响应式编程模型，底层使用 Netty（非 Servlet 容器），少量线程处理大量并发： 请求进来 → 少量线程（CPU 核数）→ 发起数据库查询（注册回调，线程立刻去处理其他请求）→ 数据返回时触发回调继续处理 编程模型 WebFlux 使用 Reactor 库的 Mono<T>（0 或 1 个异步结果）和 Flux<T>（0 到 N 个异步结果）： // Spring MVC（同步阻塞） @GetMapping("/users/{id}") public User getUser(@PathVariable Long id) { return userService.findById(id); // blocks on DB } // Spring WebFlux（异步非阻塞） @GetMapping("/users/{id}") public Mono<User> getUser(@PathVariable Long id) { return userService.findById(id); // returns a deferred result } WebFlux 的局限 编程模型与传统命令式完全不同，调试困难，学习成本高 需要支持响应式的驱动（R2DBC 替代 JDBC），不是所有库都有响应式版本 Java 21 虚拟线程的出现大幅削弱了 WebFlux 在普通业务系统里的核心优势（见 Java Virtual Threads） 何时仍选 WebFlux SSE 实时推送 需要背压控制（消费者告知生产者降速）的流式处理 已有 WebFlux 项目：继续用即可，不必为并发改回 MVC Java 网络层全景 主流 Java Web 栈最终归为两大谱系： ...