为何Spring Boot阻塞API比Project Reactor更快？测试存疑求助

测试结果截图 #

• 阻塞API结果：
• Project Reactor结果：

核心原因分析 #

• 测试场景未匹配响应式编程的优势区间
  Project Reactor这类响应式框架的价值，是在高IO密集、高并发长连接的场景下，通过非阻塞线程模型减少资源浪费，提升系统吞吐量。但你的测试中数据库仅有10条记录，IO耗时几乎可以忽略，此时响应式框架的线程调度、上下文切换等额外开销反而成为性能负担，自然跑不过无额外开销的纯阻塞API。

• 可能存在“伪响应式”实现
  如果你的Reactor应用底层还是用了JDBC这类阻塞式数据库驱动，而非R2DBC这类真正的响应式数据库驱动，那么整个链路只是套了一层Reactor的壳，本质还是阻塞操作。这种情况下，线程切换的额外成本会直接拉低整体性能。

• 线程模型配置不合理
  基于WebFlux的响应式应用默认使用少量的EventLoop线程处理请求，如果你的业务逻辑不小心在这些线程中执行了阻塞操作，或者订阅线程池配置不当，会导致线程调度效率下降，进而拖慢整体响应速度。

• 测试流程的局限性

  • 缺少预热阶段：测试前未进行足够的请求预热，JVM尚未完成JIT编译，响应式框架的初始化开销会被放大。
  • 负载场景不匹配：400线程循环40次的压力下，阻塞API的线程池（如Tomcat默认线程池）刚好适配低IO负载，而响应式模型的优势无法在这种场景下体现。

优化建议 #

1. 调整测试场景：增加数据库记录量，或通过工具模拟慢查询引入IO延迟，再对比两者在高IO压力下的性能表现。
2. 全链路响应式改造：替换JDBC为R2DBC，确保从数据库访问到Web层的全链路都是非阻塞的响应式实现。
3. 优化线程配置：避免在EventLoop线程中执行阻塞操作，必要时配置专用的业务线程池处理耗时逻辑。
4. 完善测试流程：加入预热环节（比如先跑100次请求再正式测试），多次测试取平均值，提升结果的可靠性。

内容的提问来源于stack exchange，提问作者Anothereno