在阻塞编程模式里，任何一个请求，都需要一个线程去处理，如果io阻塞了，那么这个线程也会阻塞在那，此时会有一个线程卡在那卡10秒。
线程资源是很珍贵的，这种大延迟的场景并发量很难上去，毕竟一个并发就消耗一个线程。
而webflux里面，一个请求进来，除了一些数据封装，其他逻辑都放到worker线程里执行，在io阻塞的时候，实际上是把数据直接写入socket就不管了，不需要消耗一个线程。
一直等到对方发回数据，再拿一个worker线程去处理数据，这中间只需要一些内存保存上下文信息，基本不消耗任何其他资源，这也就是webflux特别推荐的场景:io集中并且延迟较大，并且延迟越大优势体现越明显。
若在非Reactive模式下执行完需要10s，那么用了WebFlux返回给前端的耗时还是10s。
WebFlux真正的意义是，当耗时的，像访问文件或者数据库那样的处理发生时，它可以把使用的线程让渡出来，供其它请求去使用。
所以它提高的是整个系统的吞吐率，而不是单个请求的执行速度（甚至比非Reactive稍慢），JDBC等访问方式也在慢慢朝Reactive过度。
对前端来说，每个请求的处理速度并未变快，但是后端却可以更充分的提高硬件利用率，能处理更多的请求，提高后端系统的整体并发量。
什么webFlux的delay方法没有阻塞线程，因为它的延时处理都交给了ScheduledExecutorService执行器处理，调用delay方法的主线程就直接返回了，
等到延时时间过后，ScheduledExecutorService就会从线程池就获取一个线程来处理延时后的任务逻辑。
通过反应式编程范式，将所有阻塞都修改为类似于delay之于sleep的形式，就能大幅度提升服务性能了。
最后，也是非常重要的一点：异步非阻塞并不会使程序运行得更快。
WebFlux并不能使接口的响应时间缩短，它仅仅能够提升后端服务吞吐量和伸缩性。
SpringWebFlux作为一个异步非阻塞的Web框架，它特别适合应用在IO密集型的服务中，比如微服务网关这样的网络IO密集型应用中。
Reactive and non-blocking generally do not make applications run faster.