SpringMVC同步与异步请求-蒲公英云

前言

   使用异步servlet主要原因就是因为，在service方法中业务逻辑如果碰到io操作时间比较长的操作，这样这个service方法就会长时间占用tomcat容器线程池中的线程，这样是不利于其他请求的处理的，当线程池中的线程处理任务时，任务由于长时间io操作，肯定会阻塞线程处理其他任务，引入异步servlet的目的就是将容器线程池和业务线程池分离开。在处理大io的业务操作的时候，把这个操作移动到业务线程池中进行，释放容器线程，使得容器线程处理其他任务，在业务逻辑执行完毕之后，然后在通知tomcat容器线程池来继续后面的操作，这个操作应该是把处理结果commit到客户端或者是dispatch到其他servlet上。原始模型在处理业务逻辑的过程中会一直占有容器线程池，而异步servlet模型，可以看出在业务线程池处理的过程中，有一段时间容器线程池中的那个线程是空闲的，这种设计大大提高了容器的处理请求的能力。

什么是异步模式

要知道什么是异步模式，就先要知道什么是同步模式，先看最典型的同步模式：

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70

   浏览器发起请求，Web服务器开一个线程处理，处理完把处理结果返回浏览器。好像没什么好说的了，绝大多数Web服务器都如此般处理。现在想想如果处理的过程中需要调用后端的一个业务逻辑服务器，会是怎样呢？

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1

    调就调吧，上图所示，请求处理线程会在Call了之后等待Return，自身处于阻塞状态。这也是绝大多数Web服务器的做法，一般来说这样做也够了，为啥？一来“长时间处理服务”调用通常不多，二来请求数其实也不多。要不是这样的话，这种模式会出现什么问题呢？——会出现的问题就是请求处理线程的短缺！因为请求处理线程的总数是有限的，如果类似的请求多了，所有的处理线程处于阻塞的状态，那新的请求也就无法处理了，也就所谓影响了服务器的吞吐能力。要更加好地发挥服务器的全部性能，就要使用异步，这也是标题上所说的“高性能的关键”。接下来我们来看看异步是怎么一回事：

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2

    最大的不同在于请求处理线程对后台处理的调用使用了“invoke”的方式，就是说调了之后直接返回，而不等待，这样请求处理线程就“自由”了，它可以接着去处理别的请求，当后端处理完成后，会钩起一个回调处理线程来处理调用的结果，这个回调处理线程跟请求处理线程也许都是线程池中的某个线程，相互间可以完全没有关系，由这个回调处理线程向浏览器返回内容。这就是异步的过程。

带来的改进是显而易见的，请求处理线程不需要阻塞了，它的能力得到了更充分的使用，带来了服务器吞吐能力的提升。

Spring MVC的使用——DefferedResult

要使用Spring MVC的异步功能，你得先确保你用的是Servlet 3.0或以上的版本，Maven中如此配置：

<dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>3.1.0</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>4.2.3.RELEASE</version>
</dependency>

由于Spring MVC的良好封装，异步功能使用起来出奇的简单。传统的同步模式的Controller是返回ModelAndView，而异步模式则是返回DeferredResult。

看这个例子：

@RequestMapping(value="/asynctask", method = RequestMethod.GET)
public DeferredResult<ModelAndView> asyncTask(){
    DeferredResult<ModelAndView> deferredResult = new DeferredResult<ModelAndView>();
    System.out.println("/asynctask 调用！thread id is : " + Thread.currentThread().getId());
    longTimeAsyncCallService.makeRemoteCallAndUnknownWhenFinish(new LongTermTaskCallback() {
        @Override
        public void callback(Object result) {
            System.out.println("异步调用执行完成, thread id is : " + Thread.currentThread().getId());
            ModelAndView mav = new ModelAndView("remotecalltask");
            mav.addObject("result", result);
            deferredResult.setResult(mav);
        }
    });
}

longTimeAsyncCallService是我写的一个模拟长时间异步调用的服务类，调用之，立即返回，当它处理完成时候，就钩起一个线程调用我们提供的回调函数，这跟“图3”描述的一样，它的代码如下：

public interface LongTermTaskCallback {
    void callback(Object result);
}
public class LongTimeAsyncCallService {
    private final int CorePoolSize = 4;
    private final int NeedSeconds = 3;
    private Random random = new Random();
    private ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(CorePoolSize);
    public static void makeRemoteCallAndUnknownWhenFinish(LongTermTaskCallback callback){
        System.out.println("完成此任务需要 : " + NeedSeconds + " 秒");
        scheduler.schedule(new Runnable() {
            @Override
            public void run() {
                callback.callback("长时间异步调用完成.");
            }
        }, "这是处理结果:)", TimeUnit.SECONDS);
    }
}

输出的结果是：

/asynctask 调用！thread id is : 46
完成此任务需要 : 3 秒
异步调用执行完成, thread id is : 47

由此可见返回结果的线程和请求处理线程不是同一线程。

Callable方式

   返回DefferedResult<ModelAndView>并非唯一做法，还可以返回WebAsyncTask来实现“异步”，但略有不同，不同之处在于返回WebAsyncTask的话是不需要我们主动去调用Callback的，看例子：
@RequestMapping(value="/longtimetask", method = RequestMethod.GET)
public WebAsyncTask longTimeTask(){
    System.out.println("/longtimetask被调用 thread id is : " + Thread.currentThread().getId());
    Callable<ModelAndView> callable = new Callable<ModelAndView>() {
        @Override
        public ModelAndView call() throws Exception {
            Thread.sleep(3000); //假设是一些长时间任务
            ModelAndView mav = new ModelAndView("longtimetask");
            mav.addObject("result", "执行成功");
            System.out.println("执行成功 thread id is : " + Thread.currentThread().getId());
            return mav;
        }
    };
    return new WebAsyncTask(callable);
}

很明显可知：请求进入时拦截了一次，将Callable返回结果时，将请求重新派发给容器时又拦截了一次，所以进了两次拦截；

其核心是一个Callable，事实上，直接返回Callable都是可以的，但我们这里包装了一层，以便做后面提到的“超时处理”。和前一个方案的差别在于这个Callable的call方法并不是我们直接调用的，而是在longTimeTask返回后，由Spring MVC用一个工作线程来调用，执行，打印出来的结果：

/longtimetask被调用 thread id is : 56
执行成功 thread id is : 57

可见确实由不同线程执行的，但这个WebAsyncTask可不太符合“图3”所描述的技术规格，它仅仅是简单地把请求处理线程的任务转交给另一工作线程而已。

Callable主要用来处理一些简单的逻辑，DeferredResult主要用于处理一些复杂逻辑