运行在主线程的Reactor操作符如flatMap比普通阻塞代码效率更高吗？

很多人会误以为响应式的优势就是多线程并行，这是完全错误的认知。响应式的核心价值是线程无阻塞复用，哪怕单线程场景也能大幅提升IO密集型场景的资源利用率。

两段示例代码的核心执行逻辑差异 #

二者的性能差异完全取决于makeAReactiveMethodCall的实现逻辑：

• 如果这个方法是纯CPU同步计算，没有任何IO等待（比如只是对入参做加减乘除）：那两段代码性能差异极小，甚至flatMap版本因为有响应式流的额外封装开销，性能还会略低于直接for循环，这种场景本来就不是响应式的适用场景。
• 如果这个方法是IO密集型操作（比如调用远程HTTP接口、查询数据库、读写文件等）：二者的性能天差地别，核心差异如下：
  • forEach+block版本：6次调用完全串行执行，每次调用都会把当前main线程阻塞挂起，等待本次IO返回后才会发起下一次调用。总耗时约等于6次IO的耗时之和，全程main线程处于闲置阻塞状态，完全没有被利用。
  • flatMap版本：main线程会一次性连续发起6次IO请求，发起后不会等待任何IO返回，线程可以被释放去处理其他任务；待任意IO请求有结果返回后，再回调到main线程处理结果。6次IO是并行执行的，总耗时约等于最慢的1次IO的耗时，全程main线程没有被阻塞浪费，资源利用率极高。

关于“是不是只有切线程才能体现响应式优势”的解答 #

不是。

• 对于IO密集型场景，哪怕全程只用单线程，响应式的非阻塞特性也能让单线程扛住远高于阻塞模式的吞吐量：阻塞模式下单线程同一时间只能等1个IO，非阻塞模式下单线程可以同时管理成百上千个IO请求的等待和回调。
• Schedulers线程切换的作用，更多是用来处理CPU密集型计算任务：如果你的流里有CPU密集的运算逻辑，把这部分逻辑调度到Schedulers.parallel()等独立线程池，可以避免占住负责IO回调的调度线程，阻塞其他IO任务的处理。

为什么示例的日志都打印main线程 #

Reactor操作符默认遵循上下文线程传递规则：你没有显式通过publishOn/subscribeOn指定调度器的前提下，操作符的处理逻辑会沿用上游信号触发的线程，你这里是从main线程发起的订阅，所以结果回调的日志自然都打印main线程。但这完全不影响6次IO请求是并行发起、并行等待的特性，这也是非阻塞模式和阻塞模式最核心的区别。

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