牛皮的异步非阻塞(webFlux)

异步非阻塞，我感觉比较关键的一点就是延迟执行，tomcat处理请求的线程不是阻塞的，而是将处理的逻辑丢给另一个线程去处理，因此，这个线程不是阻塞的。

具体的理论指导，我觉得这篇文章写得不错：
异步非阻塞的原理

里面有一段话 我觉得讲的很好：

那么当有200个线程同时并发在处理,那么当来201个请求的时候,就已经处理不了，因为所有的线程都阻塞了。这是3.0之前的处理情况

而3.0之后异步处理是怎样处理呢？学过Netty通信框架的同学会比较容易理解一点，Servlet3.0类似于Netty一样就一个boss线程池和work线程池，boss线程只负责接收请求,work线程只负责处理逻辑。那么servlet3.0规范中，这200个线程只负责接收请求，然后每个线程将收到的请求，转发到work线程去处理。因为这200个线程只负责接收请求，并不负责处理逻辑，故不会被阻塞，而影响通信，就算处理非常耗时，也只是对work线程形成阻塞，所以当再来请求，同样可以处理,其主要应用场景是针对业务处理较耗时的情况可以减少服务器资源的占用，并且提高并发处理速度。

下面是我的代码的演示：

@GetMapping("/delay1")
    public Mono<RestResult> delayResult() {
        long l = System.currentTimeMillis();

        Mono<RestResult> resultMono = Mono.fromSupplier(()->{
            try {
                Thread.sleep(5_000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return new RestResult().setMessage("hello world!!");

        });
        long r = System.currentTimeMillis();
        log.info("执行时间 {} ！！",(r-l));
        return resultMono;
    }


@GetMapping("/delay2")
    public  RestResult  delayResult2() {
        long l = System.currentTimeMillis();
        Supplier<RestResult> result = () -> {
            try {
                Thread.sleep(5_000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return new RestResult<>().setMessage("ok");
        };
        RestResult restResult = result.get();
        long r = System.currentTimeMillis();

        log.info("执行时间 {} ！！",(r-l));
        return restResult;
    }

对于业务逻辑，假设 处理这个业务 耗时 5秒，而处理请求的 线程如果可以立刻返回的话，请求线程就是异步非阻塞的：
下面是代码打印结果：

请求 delay1 接口，tomcat 线程处理接收到后，立刻返回，而处理第二个接口，tomcat线程则是阻塞，等到处理完毕后再返回。
虽然目前请求量少，体现不出区别，但是，当请求量非常大的时候，异步非阻塞的好处就会看到了。