Project Reactor：flatMap内嵌套Mono.just处理非响应式操作的收益分析

直接给结论：把非响应式阻塞操作包在Mono.just()里丢进flatMap，完全没有收益，只会增加不必要的响应式包装开销。

两种写法的实际执行逻辑 #

• 对于map(data -> outboundCall(data))：
  map是同步操作符，outboundCall这个阻塞方法会直接在当前订阅者所在的线程上同步执行，执行完后把结果包装成信号往下传递。整个过程没有额外的响应式对象创建开销，但缺点是会阻塞当前线程。

• 对于flatMap(data -> Mono.just(outboundCall(data)))：
  别被flatMap的“异步”属性迷惑——Mono.just()是立即执行的，也就是说outboundCall还是会在当前线程同步跑完，然后才把结果包装成Mono交给flatMap去订阅展开。这比单纯用map多了一层Mono的创建、订阅、信号传递的开销，却完全没实现异步非阻塞的效果。

真正实现异步非阻塞的正确姿势 #

如果想让阻塞操作不占用主线程（比如Spring WebFlux里的Netty IO线程），得把阻塞操作放到专门的线程池里执行，正确写法是用Mono.fromCallable()配合subscribeOn()：

.flatMap(data -> Mono.fromCallable(() -> outboundCall(data))
                     .subscribeOn(Schedulers.boundedElastic()))

这里fromCallable会把阻塞操作延迟到订阅阶段执行，subscribeOn指定了专门处理阻塞任务的线程池，这样主线程就不会被阻塞，真正实现响应式框架要求的异步非阻塞。

总结 #

• 用flatMap(Mono.just(...))处理阻塞操作：纯纯的无用功，白加开销。
• 用map处理阻塞操作：简单但会阻塞当前线程，在高并发场景下可能拖垮系统吞吐量。
• 正确做法：fromCallable+subscribeOn+flatMap，既解决阻塞问题，又符合响应式编程的最佳实践。

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