Spring WebFlux 性能调优——线程模型、调度器、实测对比 Spring MVC
Spring WebFlux 性能调优——线程模型、调度器、实测对比 Spring MVC
适读人群：对 WebFlux 性能有疑惑、想做实测决策的 Java 工程师 | 阅读时长：约16分钟 | 核心价值：搞清楚 WebFlux 真正快在哪、不快在哪，用数据说话
我见过不少人在选型时的思路是："WebFlux 高并发，所以我应该用 WebFlux。"
这个逻辑有一个大问题：WebFlux 的性能优势不是在所有场景下都成立的。
我专门做过一组对比测试，结论让我自己也有点意外——在某些场景下，WebFlux 比 Spring MVC 慢。这篇文章把那组测试的数据和分析完整写出来，希望能帮你在选型的时候不踩坑。
一、先搞清楚两者的线程模型
Spring MVC（Tomcat）：
Tomcat 的默认线程池有200个线程。每个 HTTP 请求进来，从线程池里拿一根线程，从头干到尾，干完了再放回去。
线程利用率的问题在于：如果请求里有 IO 操作（数据库、HTTP 调用），线程会在那里挂着等，不干活但占着资源。并发量高了，200根线程全都在等 IO，新进来的请求只能排队。
Spring WebFlux（Netty）：
Netty 的 event loop 线程很少，默认是 CPU 核数 × 2（我的测试机是8核，所以是16根）。这些线程永不阻塞——做完注册 IO 回调的事情后，立刻去处理下一个请求，等数据来了再回来继续。
优势：少量线程支撑大量并发，内存占用低，线程切换开销小。
代价：响应式编程的学习成本，调试复杂度，以及——响应式本身的开销（操作符链的创建和执行不是免费的）。
二、测试环境和方法
测试机：8核16G，JVM 堆12G，JDK 21。
Spring MVC：Tomcat 线程池200（默认），JDBC + HikariCP（连接池20）。
Spring WebFlux：Netty，event loop 16线程，R2DBC（连接池20，和 MVC 保持一致）。
测试工具：Gatling，发压机在同一局域网内。
测试了4种场景：
- 纯计算（不涉及 IO）
- 轻量 IO（数据库单表查询，平均8ms）
- 重 IO（数据库复杂查询 + 2个下游 HTTP 调用，平均总延迟约280ms）
- 高混合（50%轻量IO + 50%重IO，并发500）
三、测试结果
场景1：纯计算（无IO）
| 并发 | MVC P99 | WebFlux P99 | 说明 |
|---|---|---|---|
| 100 | 11ms | 14ms | WebFlux 稍慢，操作符链的开销 |
| 500 | 17ms | 21ms | 差距相当 |
| 1000 | 34ms | 38ms | 差距相当 |
结论：纯计算场景，WebFlux 略慢于 MVC，因为响应式操作符有额外开销。
这个结果让我当时有点惊讶。后来想明白了：纯 CPU 操作，MVC 的线程模型其实没有弱点，而 WebFlux 的操作符链（Mono/Flux 的创建、操作符的执行）有额外开销。
场景2：轻量 IO
| 并发 | MVC P99 | WebFlux P99 | 说明 |
|---|---|---|---|
| 100 | 28ms | 31ms | 差距不大 |
| 500 | 89ms | 64ms | WebFlux 开始体现优势 |
| 1000 | 347ms | 97ms | MVC 线程开始排队 |
| 2000 | 超时/拒绝 | 183ms | MVC 已经扛不住 |
结论：IO场景下，并发量上来之后 WebFlux 优势明显，1000并发以上差距非常显著。
场景3：重IO（复杂查询 + HTTP调用）
| 并发 | MVC P99 | WebFlux P99 | 说明 |
|---|---|---|---|
| 100 | 312ms | 287ms | WebFlux 稍快 |
| 200 | 518ms | 301ms | WebFlux 优势开始出现 |
| 500 | 1840ms（排队） | 413ms | 差距非常大 |
| 1000 | 大量超时 | 741ms | MVC 基本不可用 |
结论：重IO是 WebFlux 最大的优势场景，高并发下差距极其显著。
场景4：混合负载，并发500
| 指标 | MVC | WebFlux |
|---|---|---|
| 吞吐量(req/s) | 1230 | 2180 |
| P50 | 287ms | 143ms |
| P99 | 1620ms | 387ms |
| 内存占用 | 约1.8GB | 约0.9GB |
| 线程数 | ~230 | ~28 |
内存减半，吞吐量几乎翻倍。这是 WebFlux 的主场。
四、调度器选择对性能的影响
调度器配置不当，WebFlux 的性能会大幅下降。
常见错误：在 event loop 线程里做阻塞操作
// 这个写法会严重影响性能
return Mono.fromCallable(() -> {
Thread.sleep(100); // 模拟阻塞操作
return "result";
});
// 默认在 event loop 线程上执行，阻塞了整个事件循环！测试数据：8核机器，上面这种写法，并发100时 P99 达到了 6200ms，因为16个 event loop 线程全被阻塞了，所有请求都在等。
正确写法：
// 阻塞操作必须切到 boundedElastic
return Mono.fromCallable(() -> {
Thread.sleep(100);
return "result";
}).subscribeOn(Schedulers.boundedElastic());加了 subscribeOn(Schedulers.boundedElastic()) 之后，同样场景 P99 从 6200ms 降到了 287ms。这个差距可以说是灾难性的。
调度器选择参考：
// CPU密集型：用 parallel()，线程数=CPU核数
Flux.range(1, 10000)
.parallel()
.runOn(Schedulers.parallel())
.map(i -> cpuHeavyCompute(i))
.sequential();
// IO密集型/阻塞操作：用 boundedElastic()
Mono.fromCallable(() -> jdbcTemplate.queryForObject(...))
.subscribeOn(Schedulers.boundedElastic());
// 定时任务：用 single()，保证顺序执行
Flux.interval(Duration.ofSeconds(1))
.publishOn(Schedulers.single())
.subscribe(tick -> doScheduledTask());五、连接池对性能的影响
R2DBC 的连接池配置也很关键，很多人用了默认配置，效果大打折扣：
spring:
r2dbc:
pool:
initial-size: 5
max-size: 50 # 根据数据库服务器性能调整，不是越大越好
max-idle-time: 30m
max-acquire-time: 3s # 等待连接的超时，超过就报错
max-create-connection-time: 5s测试数据：连接池从默认10改到50，在1000并发场景下，WebFlux P99 从 483ms 降到了 247ms。数据库查询本身没有变快，但等待连接的排队时间少了。
六、JVM 参数调优
WebFlux 的内存模型和 MVC 不同，JVM 参数也需要调整：
# 推荐的 JVM 参数
java \
-Xms2g -Xmx4g \ # 堆大小，根据实际情况调整
-XX:+UseG1GC \ # G1 GC，默认在 Java 9+
-XX:MaxGCPauseMillis=50 \ # 目标 GC 暂停时间50ms
-XX:+UseStringDeduplication \ # 字符串去重，节省内存
-Dio.netty.allocator.type=pooled \ # Netty 内存池
-Dio.netty.allocator.numDirectArenas=8 \ # 直接内存 arena 数量
-jar app.jarWebFlux 用了大量 Netty 的堆外内存（Direct Memory），默认情况下最大堆外内存等于 -Xmx。如果你的应用处理大量数据，需要关注堆外内存：
-XX:MaxDirectMemorySize=2g # 显式设置堆外内存上限七、Netty 参数调优
除了 JVM，Netty 本身也有一些调优点：
@Bean
public NettyServerCustomizer nettyServerCustomizer() {
return server -> server
.option(ChannelOption.SO_BACKLOG, 1024) // 等待连接的队列大小
.childOption(ChannelOption.SO_KEEPALIVE, true) // 保持长连接
.childOption(ChannelOption.TCP_NODELAY, true) // 禁用 Nagle，减少延迟
.childOption(ChannelOption.SO_RCVBUF, 32 * 1024) // 接收缓冲区
.childOption(ChannelOption.SO_SNDBUF, 32 * 1024); // 发送缓冲区
}Event loop 线程数也可以调整（默认 CPU 核数 × 2）：
# 如果你的服务 IO 很重（大量等待），可以适当增加 event loop 线程数
# 但不是越多越好，超过 CPU 核数太多反而会增加线程切换开销
spring:
netty:
eventloop:
worker-count: 16 # 明确设置，默认是 CPU × 2八、响应式调用链的性能监控
性能调优的前提是有好的可观测性。WebFlux 的 Micrometer 集成：
// 在 application.yml 里开启
management:
metrics:
enable:
netty: true
http.server: true
observations:
http:
server:
requests:
enabled: true关键指标监控：
// 自定义请求耗时监控
@Component
public class PerformanceFilter implements WebFilter {
@Autowired
private MeterRegistry meterRegistry;
@Override
public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
long start = System.currentTimeMillis();
String path = exchange.getRequest().getPath().value();
return chain.filter(exchange)
.doFinally(signal -> {
long duration = System.currentTimeMillis() - start;
meterRegistry.timer("http.server.requests.custom",
"path", path,
"status", String.valueOf(
exchange.getResponse().getStatusCode() != null
? exchange.getResponse().getStatusCode().value() : 0),
"outcome", signal.name()
).record(duration, TimeUnit.MILLISECONDS);
// 超过500ms的请求打警告日志
if (duration > 500) {
log.warn("慢请求: path={}, duration={}ms", path, duration);
}
});
}
}Reactor 本身的内部指标（通过 Hooks.enableContextLossTracking() 开启调试模式）：
// 开发环境开启，帮助定位 Context 丢失问题
// 注意：生产环境关闭，有性能开销
@Profile("dev")
@Configuration
public class ReactorDebugConfig {
@PostConstruct
public void enableDebug() {
Hooks.onOperatorDebug(); // 开启完整的调试模式，包含更详细的栈信息
// 或者用更轻量的 ReactorDebugAgent
}
}九、我的选型建议
基于这些测试数据，我的实际判断：
用 WebFlux 的场景：
- 服务是纯 IO 密集型，大量等待数据库/下游服务
- 需要处理大量长连接（WebSocket、SSE）
- 资源受限，希望用少量机器支撑高并发
- 并发量在几百以上，且会继续增长
继续用 Spring MVC 的场景：
- 计算密集型，IO 不多
- 并发量在200以内，MVC 的线程池完全够用
- 团队没有响应式经验，迁移成本高
- 大量依赖第三方库，没有响应式版本
- 需要快速迭代，不想因为调试复杂度拖慢进度
说到底，技术选型不是非此即彼。我现在的态度是：IO密集型高并发选 WebFlux，其他场景先评估再决定，不要因为"WebFlux 先进"就无脑切换。
下一篇写 WebFlux 与 Kafka 的集成，响应式消息处理管道是另一个很有价值的场景，我在几个项目里都用过，有挺多可以说的。