Spring WebFlux 基于 Reactor 和 Netty 实现响应式编程。对比了 Servlet 阻塞模型与 WebFlux 非阻塞模型的差异，涵盖线程模型、IO 处理、内存管理及连接处理。通过源码分析与压测数据，展示了 WebFlux 在高并发 IO 密集型场景下的优势，如事件循环机制、零拷贝及堆外内存。同时指出了常见陷阱如阻塞代码、背压处理及内存泄漏，并提供了从 Servlet 迁移到 WebFlux 的策略与优化指南。适合高并发 API 网关、实时消息推送等场景，但不适用于 CPU 密集型任务。
去年我们团队要做一个实时消息推送系统，要求支持 10 万并发长连接。开始用的 Spring MVC + Tomcat，测试时 1000 连接就崩了，Tomcat 线程池直接打满。
后来换成 WebFlux + Netty，同样的机器配置，10 万连接稳稳的。但高兴得太早，上线后发现 CPU 使用率比原来高了 30%。排查发现是有个同事在响应式链里写了阻塞代码。
还有个更坑的：我们有个批量查询接口，用 WebFlux 重写后，响应时间反而变长了。查了三天，发现是因为没处理好背压，数据量大的时候内存暴涨。
这些经历让我明白：不懂原理的技术选型就是耍流氓，WebFlux 不是银弹，用错了比不用还惨。
Spring WebFlux 是响应式 Web 框架，基于 Reactor 和 Netty 实现。本文深度对比 Servlet 阻塞模型与响应式非阻塞模型的差异，从线程模型、IO 处理、内存管理三个维度解析性能关键。通过源码分析揭示 WebFlux 的请求处理流程、编解码机制、错误处理策略。结合压测数据和实战案例，提供 WebFlux 的正确使用姿势和性能优化指南。
很多人盲目追新技术，我总结了几个判断标准：
适合 WebFlux 的场景：
不适合 WebFlux 的场景：
先看个真实的性能对比，这是我们在 4 核 8G 机器上的测试结果：
| 场景 | Spring MVC (Tomcat) | WebFlux (Netty) | 提升 |
|---|---|---|---|
| 100 并发，简单查询 | 3200 QPS | 3500 QPS | 9.4% |
| 1000 并发，简单查询 | 2800 QPS | 5200 QPS | 85.7% |
| 100 并发，IO 密集 | 1200 QPS | 3800 QPS | 216.7% |
| 内存占用（1000 连接） | 450MB | 320MB | 28.9% |
看到没？只有在高并发和 IO 密集型场景下，WebFlux 才有明显优势。
这是 Servlet 最经典的模型，也是最大的瓶颈：
// Tomcat 的线程池处理请求
public class Http11Processor implements Runnable {
public void run() {
try {
// 1. 解析请求
parseRequest();
// 2. 调用 Servlet（线程在这里阻塞！）
servlet.service(request, response);
// 3. 返回响应
writeResponse();
} catch (Exception e) {
handleError(e);
}
}
}
// Spring MVC 的 Controller
@RestController
public class UserController {
@GetMapping("/user/{id}")
public User getUser(@PathVariable Long id) {
// 线程在这里阻塞，等待数据库查询
return userRepository.findById(id).orElse(null);
}
}
代码清单 1：Servlet 线程模型
问题：线程在等待 IO 时被阻塞，什么也干不了，浪费资源。
WebFlux 用了完全不同的思路：
// Netty 的事件循环
public class NioEventLoop extends SingleThreadEventLoop {
protected void run() {
for (;;) {
try {
// 1. 选择就绪的 IO 事件
int readyChannels = selector.select();
if (readyChannels > 0) {
// 2. 处理 IO 事件
processSelectedKeys();
}
// 3. 处理任务队列
runAllTasks();
} catch (Throwable t) {
handleLoopException(t);
}
}
}
}
// WebFlux 的 Controller
@RestController
public class UserController {
@GetMapping("/user/{id}")
public Mono<User> getUser(@PathVariable Long id) {
// 立即返回 Publisher，不阻塞
return userRepository.findById(id)
.subscribeOn(Schedulers.boundedElastic());
}
}
代码清单 2：WebFlux 事件循环模型
响应式模型的工作方式：
关键点：事件循环线程只做 IO 调度，耗时操作交给工作线程池，处理完回调。
看 Spring MVC 是怎么处理请求的：
// DispatcherServlet 的核心流程
public class DispatcherServlet extends FrameworkServlet {
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
// 1. 获取 Handler
HandlerExecutionChain mappedHandler = getHandler(request);
// 2. 获取 HandlerAdapter
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// 3. 执行拦截器前置处理
if (!mappedHandler.applyPreHandle(request, response)) {
return;
}
// 4. 实际处理（这里线程被阻塞！）
ModelAndView mv = ha.handle(request, response, mappedHandler.getHandler());
// 5. 渲染视图
mappedHandler.applyPostHandle(request, response, mv);
processDispatchResult(request, response, mappedHandler, mv, null);
}
}
代码清单 3：Spring MVC 请求处理
看到没？线程大部分时间在等待，啥也干不了。
WebFlux 的处理方式完全不同：
// DispatcherHandler 的核心流程
public class DispatcherHandler implements WebHandler {
public Mono<Void> handle(ServerWebExchange exchange) {
return Flux.fromIterable(this.handlerMappings)
.concatMap(mapping -> mapping.getHandler(exchange))
.next()
.switchIfEmpty(createNotFoundError())
.flatMap(handler -> invokeHandler(exchange, handler))
.flatMap(result -> handleResult(exchange, result));
}
private Mono<HandlerResult> invokeHandler(ServerWebExchange exchange, Object handler) {
// 找到合适的 HandlerAdapter
HandlerAdapter adapter = getHandlerAdapter(handler);
// 执行业务逻辑（返回 Mono，不阻塞）
return adapter.handle(exchange, handler);
}
}
代码清单 4：WebFlux 请求处理
关键优势：事件循环线程永不阻塞，一个线程能处理成千上万的连接。
Servlet 使用的是传统的堆内存：
// 典型的 Servlet 内存使用
public class UserController {
@PostMapping("/upload")
public String upload(@RequestParam("file") MultipartFile file) {
// 整个文件被读到堆内存！
byte[] bytes = file.getBytes();
// 内存峰值
// 处理文件
processFile(bytes);
return "success";
}
}
内存分配情况：
WebFlux 利用 Netty 的零拷贝和堆外内存：
@RestController
public class FileController {
@PostMapping(value = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public Mono<String> upload(FilePart file) {
// 使用数据流，不一次性加载到内存
return file.content()
.map(dataBuffer -> {
// 直接操作数据缓冲区
byte[] bytes = new byte[dataBuffer.readableByteCount()];
dataBuffer.read(bytes);
DataBufferUtils.release(dataBuffer);
return bytes;
})
.collectList()
.flatMap(chunks -> {
// 合并处理
return processChunks(chunks);
});
}
// 文件下载：零拷贝
@GetMapping(value = "/download/{id}", produces = MediaType.APPLICATION_OCTET_STREAM_VALUE)
public Mono<Resource> download(@PathVariable String id) {
return Mono.fromCallable(() -> new FileSystemResource("/data/files/" + id));
}
}
代码清单 5：WebFlux 文件处理
性能测试（上传 100MB 文件，100 并发）：
| 指标 | Spring MVC | WebFlux | 对比 |
|---|---|---|---|
| 内存峰值 | 2.5GB | 800MB | 减少 68% |
| GC 时间 | 4.2s | 0.8s | 减少 81% |
| 平均耗时 | 3.4s | 1.8s | 减少 47% |
Tomcat 默认使用短连接，每个请求创建新连接：
// Tomcat 连接处理
public class Http11Processor {
public void action(ActionCode actionCode, Object param) {
switch (actionCode) {
case CLOSE:
// 关闭连接
endRequest();
break;
// ...
}
}
private void endRequest() {
// 释放连接资源
inputBuffer.recycle();
outputBuffer.recycle();
// 如果是短连接，关闭 Socket
if (!isKeepAlive()) {
closeSocket();
}
}
}
问题：
Netty 天生支持长连接：
// WebFlux 的 HTTP/2 支持
@Configuration
public class Http2Config {
@Bean
public NettyServerCustomizer nettyServerCustomizer() {
return httpServer -> httpServer
.protocol(HttpProtocol.H2, HttpProtocol.HTTP11)
.compress(true)
.http2Settings(settings -> settings.maxConcurrentStreams(1000L));
}
}
// WebSocket 支持
@RestController
public class ChatController {
@MessageMapping("chat")
public Flux<Message> chat(Flux<Message> inbound) {
return inbound
.doOnNext(message -> log.info("收到消息：{}", message))
.doOnComplete(() -> log.info("连接关闭"));
}
}
连接数对比测试（10 万并发连接）：
现实案例：我们做的消息推送系统，用 Tomcat 最多支撑 5000 长连接，用 Netty 轻松 10 万连接。
Servlet 的错误处理是同步的：
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(Exception.class)
public ResponseEntity<String> handleException(Exception e) {
// 同步处理错误
return ResponseEntity.status(500)
.body("错误：" + e.getMessage());
}
}
// 问题：如果异常处理器本身抛异常？
@ExceptionHandler(NullPointerException.class)
public ResponseEntity<String> handleNPE(NullPointerException e) {
String msg = e.getMessage();
// 可能 NPE！
return ResponseEntity.status(500).body(msg);
}
WebFlux 的错误处理是响应式的：
@ControllerAdvice
public class GlobalErrorWebExceptionHandler implements ErrorWebExceptionHandler {
public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
return Mono.fromRunnable(() -> {
// 可以在这里记录日志
log.error("处理请求异常", ex);
})
.then(Mono.defer(() -> {
// 构建错误响应
ServerHttpResponse response = exchange.getResponse();
response.setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
byte[] bytes = ("错误：" + ex.getMessage()).getBytes(UTF_8);
DataBuffer buffer = response.bufferFactory().wrap(bytes);
return response.writeWith(Mono.just(buffer));
}))
.onErrorResume(e -> {
// 错误处理器本身出错时的 fallback
log.error("错误处理器异常", e);
return Mono.empty();
});
}
}
代码清单 6：WebFlux 错误处理
我们需要一个高性能 API 网关，要求：
@Configuration
public class GatewayConfig {
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
return builder.routes()
.route("user_service", r -> r
.path("/api/users/**")
.filters(f -> f
.addRequestHeader("X-Request-ID", UUID.randomUUID().toString())
.circuitBreaker(config -> config
.setName("userService")
.setFallbackUri("forward:/fallback/user"))
.requestRateLimiter(config -> config
.setRateLimiter(redisRateLimiter()))
.retry(config -> config
.setRetries(3)
.setStatuses(HttpStatus.SERVICE_UNAVAILABLE)))
.uri("lb://user-service"))
.build();
}
@Bean
public RedisRateLimiter redisRateLimiter() {
return new RedisRateLimiter(100, 200, 1);
}
}
// 全局过滤器
@Component
public class AuthFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String token = exchange.getRequest()
.getHeaders().getFirst("Authorization");
(token == ) {
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
exchange.getResponse().setComplete();
}
validateToken(token)
.flatMap(valid -> {
(valid) {
chain.filter(exchange);
} {
exchange.getResponse()
.setStatusCode(HttpStatus.UNAUTHORIZED);
exchange.getResponse().setComplete();
}
});
}
Mono<Boolean> {
webClient.post()
.uri()
.bodyValue( (token))
.retrieve()
.bodyToMono(TokenResponse.class)
.map(TokenResponse::isValid)
.timeout(Duration.ofSeconds())
.onErrorReturn();
}
}
代码清单 7：Spring Cloud Gateway 配置
测试环境：
测试结果：
| 场景 | Spring Cloud Zuul | Spring Cloud Gateway | 提升 |
|---|---|---|---|
| 100 并发，简单路由 | 4200 QPS | 18500 QPS | 340% |
| 1000 并发，复杂过滤 | 1200 QPS | 8500 QPS | 608% |
| 长连接支持 | 差 | 优秀 | - |
| 内存占用 | 650MB | 320MB | 51% |
这是 WebFlux 最常见的问题：
// 错误：在响应式链中阻塞
@GetMapping("/blocking")
public Mono<String> blocking() {
return Mono.fromCallable(() -> {
Thread.sleep(1000); // 阻塞！
return "done";
});
}
// 正确：使用调度器
@GetMapping("/non-blocking")
public Mono<String> nonBlocking() {
return Mono.fromCallable(() -> {
Thread.sleep(1000);
return "done";
})
.subscribeOn(Schedulers.boundedElastic());
}
// 使用 BlockHound 检测阻塞调用
@PostConstruct
public void init() {
BlockHound.install();
}
响应式编程容易内存泄漏：
// 监控内存使用
@RestController
public class MetricsController {
@GetMapping("/metrics/memory")
public Mono<Map<String, Object>> memoryMetrics() {
return Mono.fromCallable(() -> {
Runtime runtime = Runtime.getRuntime();
Map<String, Object> metrics = new HashMap<>();
metrics.put("totalMemory", runtime.totalMemory());
metrics.put("freeMemory", runtime.freeMemory());
metrics.put("maxMemory", runtime.maxMemory());
metrics.put("directMemory", PlatformDependent.usedDirectMemory());
return metrics;
});
}
}
// 使用 JVM 参数开启详细 GC 日志
// -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
// 1. 开启操作符堆栈跟踪
Hooks.onOperatorDebug();
// 2. 添加检查点
flux.checkpoint("source")
.map(...)
.checkpoint("afterMap")
.subscribe();
// 3. 使用 Micrometer 监控
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return registry -> registry.config()
.commonTags("application", "webflux-demo");
}
// 4. 记录慢请求
@Bean
public WebFilter slowRequestFilter() {
return (exchange, chain) -> {
long start = System.currentTimeMillis();
return chain.filter(exchange)
.doFinally(signal -> {
long cost = System.currentTimeMillis() - start;
if (cost > 1000) {
log.warn("慢请求：{} {}, 耗时：{}ms", exchange.getRequest().getMethod(), exchange.getRequest().getPath(), cost);
}
});
};
}
# application.yml
spring:
webflux:
client:
max-connections: 1000
max-memory-size: 10MB
server:
netty:
connection-timeout: 30s
idle-timeout: 60s
reactor:
schedulers:
default-pool-size: 4
bounded-elastic:
max-threads: 200
queue-size: 10000
ttl: 60
// 使用直接内存池
@Bean
public NettyServerCustomizer nettyServerCustomizer() {
return server -> server
.metrics(true, () -> new MicrometerChannelMetricsRecorder("server", "http"))
.accessLog(true)
.runOn(LoopResources.create("webflux", 4, true))
.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);
}
// 监控直接内存
@Scheduled(fixedRate = 5000)
public void monitorDirectMemory() {
long used = PlatformDependent.usedDirectMemory();
long max = PlatformDependent.maxDirectMemory();
if (used > max * 0.8) {
log.warn("直接内存使用过高：{}/{}", used, max);
}
}
@GetMapping("/stream")
public Flux<Data> streamData() {
return dataService.getDataStream()
.onBackpressureBuffer(1000, BufferOverflowStrategy.DROP_OLDEST)
.doOnNext(data -> metrics.recordDataProcessed())
.delayElements(Duration.ofMillis(10)) // 控制速率
.timeout(Duration.ofSeconds(30))
.doOnError(TimeoutException.class, e -> log.error("数据流超时"));
}
不要一次性重写整个系统：
// 1. 混合使用
@Configuration
public class HybridConfig {
// WebFlux 路由
@Bean
public RouterFunction<ServerResponse> webFluxRoutes() {
return RouterFunctions.route()
.GET("/reactive/users", this::getUsers)
.build();
}
// Spring MVC Controller
@RestController
@RequestMapping("/mvc")
public class MvcController {
@GetMapping("/users")
public List<User> getUsers() {
return userService.getUsers();
}
}
}
// 2. 响应式调用阻塞服务
@Service
public class HybridService {
public Mono<List<User>> getUsersReactive() {
return Mono.fromCallable(() -> // 调用现有的阻塞服务
blockingUserService.getUsers()
)
.subscribeOn(Schedulers.boundedElastic())
.flatMapMany(Flux::fromIterable)
.collectList();
}
}
WebFlux 不是 Spring MVC 的替代品，它们是解决不同问题的工具。就像螺丝刀和锤子，用对了事半功倍，用错了事倍功半。
我见过太多团队在技术选型上犯错：有的在简单 CRUD 系统上用 WebFlux，复杂度增加但收益不大；有的在高并发场景下死守 Servlet，性能上不去还怪硬件不行。
记住：技术是为业务服务的，选型要结合业务场景、团队能力、运维成本综合考虑。
最后建议：不要因为 WebFlux"时髦"就用它。先分析你的业务场景，做个小规模 POC 测试，用数据说话。记住：先验证，后落地；先小范围，后推广。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online