DeferredResult 是如何实现异步处理请求的

最近遇到了一个问题，我们的一个接口需要去轮询另一个第三方接口，导致这个接口占用了太多工作线程，这些工作线程长时间 running，我们需要解决这个问题。
于是，我们的方案是：用 DeferredResult 实现接口异步。
我们下面讲讲原理 …

DeferredResult 所属包：package org.springframework.web.context.request.async;
我们先实测一波：

    @PostMapping("/pay3")
    public DeferredResult<Integer> pay3() {
        log.info("开始支付3...");

        DeferredResult<Integer> result = new DeferredResult<>(60000L);
        new Thread(() -> {
            try {
                result.setResult(checkPayStatus());
            } catch (Throwable cause) {
                result.setErrorResult(cause.getMessage());
            }
        }).start();
        return result;
    }
    
    private Integer checkPayStatus() {
        for (int i = 0; i < 5; i++) {
            try {
                log.info("查询支付状态，第 {} 次查询", i);
                Thread.sleep(10000L);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
        log.info("查询支付状态返回成功");
        return 1;
    }

工作线程 XNIO-1 task-2
创建线程后，就跑到了最后的返回。

按以前都是直接返回结果了，但是由于我们是声明了 DeferredResult 作为 SpringMVC 的返回参数，则此时返回结果并没有真的返回（接口没有返回），但工作线程也没有被阻塞住，工作线程为 WAIT 状态（TIMED_WAITING）。

工作线程是什么时候挂起的呢？
探究如下：

    @PostMapping("/pay3")
    public DeferredResult<Integer> pay3() {
        log.info("开始支付3...");

        DeferredResult<Integer> result = new DeferredResult<>(60000L);
        new Thread(() -> {
            try {
                result.setResult(checkPayStatus());
            } catch (Throwable cause) {
                result.setErrorResult(cause.getMessage());
            }
        }).start();
        try {
            log.info("返回前的主线程等待 开始..");
            Thread.sleep(100000L);
            log.info("返回前的主线程等待 结束..");
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        log.info("返回结果");
        return result;
    }

从执行结果可以看出，如果没有走到 return 结果，那么 SpringMVC 是不会将工作线程挂起的，这也很好理解。

连接是被hold住的，响应是最后才返回给客户端，我们的代码就在这中间（前提是我们开启了新线程）
而且 有别于 Callable 是 hold 住异步代码，Deferred 是 hold 住返回值。

https://stackoverflow.com/questions/17855852/difference-between-spring-mvcs-async-deferredresult-and-callable

这里用的是 ForkJoinPool.commonPool() 公共线程池去创建子工作的例子。

创建了新的线程意味着更多的计算资源，但是工作线程不会被阻塞，因此可以处理更多的请求。
这也在我们测试中被验证，如果不用此方法，我们的 undertow 容器默认的 16 工作线程根本不够用，会导致 k8s 重启 容器。

https://www.baeldung.com/spring-deferred-result

这里用的是 CompletableFuture 异步处理去创建的，跟上面是一个道理。
https://www.javacodegeeks.com/2015/07/understanding-callable-and-spring-deferredresult.html

官方文献

前半段比较有含金量，就是说 DeferredResult 是 Callable 的替代，两者都可以实现接口的异步，但是DeferredResult 是可以让子线程去协助返回的，也就是说我们有更多的操作空间。后半段就是说可以通过继承或者其他操作来完成更多的骚操作。

综上我们可以发现，几个关键词：

1. 异步工作 asynchronous task
2. 和 Callable 的相似性
3. 是springmvc的东西，不能脱离spring进行。（我们知道 Callable 是 java.util.concurrent 的东西）
4. 一般是用来处理长等待的请求。
5. 服务器释放

DeferredResult 是不能不创建子线程实现异步的。
测试如下：

    @PostMapping("/pay4")
    public DeferredResult<Integer> pay4() {
        log.info("开始支付4...");

        DeferredResult<Integer> result = new DeferredResult<>(60000L);
        result.setResult(checkPayStatus());
        return result;
    }

我们稍微思考下就可以得知，我们的长逻辑直接在工作线程中跑了，自然是阻塞了。
~~

不过，需要注意的是，对于前端，或者这个接口的调用方来说，接口依然是同步的。
我们的接口相当于一个黑盒，我们内部进行的异步让我们可以用其他线程帮助处理业务逻辑，工作线程可以去协调这些工作逻辑，从而实现同时处理更多请求。

创作不易，希望大佬们点赞、收藏、关注~