在耗时较长的Controller中使用Future异步

2019独角兽企业重金招聘Python工程师标准>>>

有一些Controller要算一些东西，可能会耗时较长，我们以休眠2秒来模拟这个过程。

代码如下

public class Dog implements Serializable {
    private String name;
    private int age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

@RestController
public class DogController {
    @GetMapping("/getdog")
    public Dog getDog() throws InterruptedException {
        Dog dog = new Dog();
        dog.setName("mimi");
        dog.setAge(1);
        Thread.sleep(2000);
        return dog;
    }
    @GetMapping("/syncgetdog")
    public Callable<Dog> syncGetDog() {
        Callable<Dog> dog = new Callable<Dog>() {
            @Override
            public Dog call() throws Exception {
                Dog midog = new Dog();
                midog.setName("mimi");
                midog.setAge(1);
                Thread.sleep(2000);
                return midog;
            }
        };
        return dog;
    }
}

这里我们使用了两种方式来获取一条狗的名字和年龄。第一种是最传统的单线程返回。第二种采用了Future模式的异步返回。我们对性能进行一次压测，压测的线程数1000，循环5次，共5000次。

我们先来压第一个getdog

压测结果如下

通过该结果我们可以看到吞吐量为96.9，最小响应时间2秒6，最大响应时间10秒3（当然这是我本机的压测，非服务器，数值量会偏小）

然后我们对异步调用进行压测

压测结果如下

吞吐量379.2，最小响应时间2秒，最大响应时间3秒。

原因主要在于单线程的程序一条道走到黑，不运行完绝不撒手，Tomcat的可用线程被完全霸占。而Future模式的异步调用则是另外启动一个线程将Callable交给TaskExecutor去处理，Tomcat自己的主线程退出，去重新接收其他的请求调用，等到Callable执行结束后，就会重新启动分配一个request请求，调用和处理Callable异步执行的返回结果，然后最终返回结果。

但这里有一点需要说明，当一个请求处理及其短时间的时候，不要使用Future模式的异步调用，性能反而不如单线程模式。

转载于:https://my.oschina.net/u/3768341/blog/2575151