【WebFlux】第一篇 —— 从同步阻塞到响应式异步

为什么我们需要 WebFlux？

在传统的 Java Web 开发中，Spring MVC 长期占据统治地位。它采用“一个请求，一个线程”（Thread-per-Request）的同步阻塞模型。在这种模型下，当请求到达 Tomcat 时，容器会从线程池中拉取一个工作线程来专门处理它。如果这个请求需要调用一个响应缓慢的第三方接口（例如耗时 2 秒的支付网关），这个线程就会被操作系统挂起，干等着 I/O 完成。

这种模式在低并发时工作良好，但在高并发场景下会迅速暴露瓶颈：宝贵的线程资源没有用在“计算”上，而是浪费在“等待”上了。如果瞬间涌入 1000 个支付请求，Tomcat 就需要准备 1000 个线程，光是线程栈内存开销就会吃掉 1GB，更别提 CPU 在线程间疯狂切换带来的性能损耗了。

为了打破这种资源瓶颈，Spring 5 引入了 WebFlux。它的核心目标是：用少得多的线程，扛住同样甚至更高的并发。

核心思维转变：从“阻塞等待”到“事件驱动”

要理解 WebFlux，首先要完成编程思维的跃迁。我们可以用“餐厅点餐”来形象地比喻这两种模型的区别：

• 传统 Spring MVC（阻塞模型）：就像去传统餐厅吃饭。你点完餐后，服务员（线程）就一直站在厨房门口等你出餐。在此期间，这个服务员无法接待其他客人。如果客人太多，餐厅就需要雇佣海量的服务员。
• WebFlux（响应式模型）：就像现代化的“取号等位”机制。你点完餐后，服务员给你一个号码牌（承诺/回调），然后立刻去服务下一位客人。当厨房做好菜后，会通过铃铛通知服务员把菜端给你。在这个过程中，服务员（线程）从未被阻塞，少数几个调度员就能服务成千上万的顾客。

在技术层面，WebFlux 默认运行在 Netty 服务器上。Netty 采用事件循环（Event Loop）模型，只需几个固定的 I/O 线程负责接收网络请求和派发事件。遇到 I/O 操作时，线程会注册回调并立即返回去处理别的请求，从而实现了极致的资源利用率。

响应式编程的基石：Reactive Streams 与背压

WebFlux 并非凭空创造概念，而是基于Reactive Streams 规范构建的。在这个规范中，数据被看作是一个个异步的“流”。而在处理这些流时，最核心的机制就是背压（Backpressure）。

在传统的异步回调中，如果数据生产者（如数据库查询）产生数据的速度，远大于消费者（如业务逻辑处理）的处理速度，消费者很容易被海量数据淹没，导致内存溢出（OOM）。

背压机制完美解决了这个问题。它允许消费者（订阅者）主动告诉生产者（发布者）：“我现在的处理能力有限，请每次只给我发送 10 条数据。” 通过这种需求协商与动态调整，响应式系统实现了优雅的流量控制，保证了系统的弹性与稳定性。

适用场景评估：WebFlux 并非万能药

虽然 WebFlux 在高并发下表现优异，但它并不适合所有场景。它的优势主要体现在：

• I/O 密集型服务：如高并发微服务网关、大量外部 API 调用的服务。
• 实时数据推送：如金融行情推送、IoT 设备数据流、SSE（Server-Sent Events）和 WebSocket。
• 云原生与 Serverless：WebFlux 配合 GraalVM 原生镜像，启动时间可优化至 100ms 以内，非常适合 Serverless 场景。

避坑提示：如果你的系统主要是 CPU 密集型计算，或者严重依赖传统的阻塞式 JDBC/JPA，强行引入 WebFlux 反而会增加代码复杂度。对于常规的 CRUD 业务，传统的 Spring MVC 依然是更稳妥的选择。

本篇小结：WebFlux 的本质是将“等待 I/O 的阻塞时间”转化为“处理其他请求的有效时间”。理解了这一底层逻辑，我们就迈出了响应式编程的第一步。

下一步预告：在下一篇笔记中，我们将正式进入代码世界，深入剖析 Reactor 框架的两大核心数据类型 Mono 与 Flux，并学习如何用“弹珠图”来可视化数据流。准备好了吗？