web服务中的阻塞和非阻塞有什么区别

spring：Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster.

在web服务中，阻塞代码模型和异步非阻塞代码模型在大多数场景下其实性能没有什么差距。甚至由于需要做更多的准备工作，异步非阻塞代码模型的性能会更差一些。这和我们的映像差别很大，这里需要弄清楚2个问题：

1. 为什么两种模型在大多数场景下没有什么性能差距？
2. 在什么样的场景下异步非阻塞代码模型会有优势？

在回答问题之前，需要明白这两种编程模型设计思想。

阻塞代码模型的典型代表是spring-mvc，他们相信当前线程是会被阻塞的，因此设计了一个包含大量线程，可灵活调整线程数量的线程池以供调用。

非阻塞异步代码模型的典型代表是spring-webflux，他们相信当前线程是不会被阻塞的，因此设计了一个仅包含少量且固定线程数的线程池以供调用。

总结的说，两种编程模型最外在的区别是线程池的大小。

现在开始回答问题。

总所周知，web服务在设计上就为了完成业务。这大多数情况下涉及到底层（数据库，文件等）的修改，修改完成才标志着业务的完成。这意味服务端代码只能等到底层修改完成才可以返回客服端。

因为上述web服务的特点，所以即使是异步非阻塞的模型也要等待异步完成才能往下执行，这相当于将异步过程同步化，所以在大多数场景下，阻塞模型和异步非阻塞模型没有什么区别。

但是异步非阻塞代码模型就是线程池小，所以在大量复杂请求下没有优势。因为就只有几个线程再跑，而且还是复杂请求，该等待还在等待，在不考虑分布式情况下，并不能充分利用机器性能进行扩展。

但是反过来想，在大量简单请求场景中，由于等待时间很短，异步非阻塞模型仅需少量线程就可以处理大量请求，这意味着性能较低的机器就可以满足其部署要求，这就有了优势。

大量简单请求的典型场景：API网关。这应该是spring-cloud-gateway选择使用spring-webflux进行开发的原因之一。