Java异步编程极大的节省了主程序执行时间，提升了计算资源利用效率，是Java高级工程师的必备技能之一。本文围绕什么是异步，异步解决了什么问题，怎么异步编程来展开。

在解释异步编程之前，我们先来看同步编程的定义。同步编程，即是一种典型的请求-响应模型，当请求调用一个函数或方法后，需等待其响应返回，然后执行后续代码。同步的最大特征便是「有序」，当各个过程都执行完毕，最后返回结果。如图

异步编程则是只发送了调用的指令，调用者无需等待被调用的方法执行完毕，而是继续执行下面的流程。在一个多处理器或多核的环境中，异步调用是真正的并行执行。如图

Java异步编程的目的是充分利用计算机CPU资源，不让主程序阻塞在某个长时间运行的任务上，从而优化主程序的执行时间。这类耗时的任务可以是 IO操作、远程调用以及高密度计算任务。如果不使用多线程异步编程，我们的系统就会阻塞在耗时的子任务上，会导致极大延长完成主函数任务的时间。

在实际业务开发中，一般都是同步调用的。但有很多场景非常适合使用异步来处理，如：注册新用户，送100个积分；或下单成功，发送push消息等等。就拿注册新用户这个用例来说，为什么要异步处理？

故，异步能解决2个问题，性能和容错性。那么想要实现异步，有哪些实现思路呢？

最常见的解决方案，是引入消息中间件。同步接口调用导致响应时间长的问题，使用mq之后，将同步调用改成异步，能够显著减少系统响应时间。

系统A作为消息的生产者，在完成本职工作后，就能直接返回结果了。而无需等待消息消费者的返回，它们最终会独立完成所有的业务功能。

这样能避免总耗时比较长，从而影响用户的体验的问题。使用消息中间件美中不足之处是：针对相对简单业务，引入第三方消息组件，可能会有些重，会带来一些额外维护工作。

如果不引入第三方中间件，我们还可以考虑通过异步非阻塞的观察者模式实现异步，比如google开源包 Guava之EventBus，可以优雅实现异步队列。

Servlet 3.0之前，Servlet采用Thread-Per-Request的方式处理请求，即每一次Http请求都由一个线程从头到尾处理。当涉及到耗时操作时，性能问题便比较明显。Servlet 3.0中提供了异步处理请求。可以先释放容器分配给请求的线程与相关资源，减轻系统负担，从而增加服务的吞吐量。Servlet 3.0的异步是通过AsyncContext对象来完成的，它可以从当前线程传给另一个线程，并归还初始线程。新的线程处理完业务可以直接返回结果给客户端。

AsyncContext对象可以从HttpServletRequest中获取：

在AsyncContext中提供了获取ServletRequest、ServletResponse和添加监听（addListener）等功能：

不仅可以通过AsyncContext获取Request和Response等信息，还可以设置异步处理超时时间。通常，超时时间（单位毫秒）是需要设置的，不然无限等下去不就与同步处理一样了。通过AsyncContext的addListener还可以添加监听事件，用来处理异步线程的开始、完成、异常、超时等事件回调。

addListener方法的参数AsyncListener的源码如下：

通常，异常或超时时返回调用方错误信息，而异常时会处理一些清理和关闭操作或记录异常日志等。

下面直接看一个基于Servlet方式的异步请求示例：

启动项目，访问对应的URL，打印日志如下：

可以看出，上述代码先执行完了主线程，也就是程序的最后一行代码的日志打印，然后才是内部线程的执行。内部线程执行完成，AsyncContext的onComplete方法被调用。如果通过浏览器访问对应的URL，还可以看到该方法的返回值“async processing”。说明内部线程的结果同样正常的返回到客户端了。

基于Spring可以通过Callable、DeferredResult或者WebAsyncTask等方式实现异步请求。

对于一次请求（/email），基于Callable的处理流程如下：

1、Spring MVC开启副线程处理业务(将Callable提交到TaskExecutor)；

2、DispatcherServlet和所有的Filter退出Web容器的线程，但是response保持打开状态；

3、Callable返回结果，SpringMVC将原始请求重新派发给容器(再重新请求一次/email)，恢复之前的处理；

4、DispatcherServlet重新被调用，将结果返回给用户；

代码实现示例如下：

访问对应URL，控制台输入日志如下：

通过日志可以看出，主线程已经完成了，副线程才进行执行。同时，URL返回结果“success”。这也说明一个问题，服务器端的异步处理对客户端来说是不可见的。

Callable默认使用SimpleAsyncTaskExecutor类来执行，该线程池不是真正意义上的线程池。值得特别注意的一点，【此处有坑】使用此线程池无法实现线程重用，每次调用都会新建一条线程。若系统中不断的创建线程，最终会导致系统占用内存过高，引发OutOfMemoryError错误，关键代码如下：

我们也可以直接通过上面的控制台日志观察，每次打印的线程名都是[task-1]、[task-2]、[task-3]、[task-4].....递增的。

正因如此，所以我们实际使用异步框架时一定要自定义线程池，替代默认的SimpleAsyncTaskExecutor。这里通过实现WebMvcConfigurer接口来完成线程池的配置。

为了验证打印的线程，我们将实例代码中的System.out.println替换成日志输出，会发现在使用线程池之前，打印日志如下：

线程名称为“task-1”。让线程池生效之后，打印日志如下：

线程名称为“thread-pool-1”，其中前面的“thread-pool”正是我们配置的线程池前缀。

除了线程池的配置，还可以配置统一异常处理，这里就不再演示了。

Spring提供的WebAsyncTask是对Callable的包装，提供了更强大的功能，比如：处理超时回调、错误回调、完成回调等。

访问对应请求，打印日志：

DeferredResult使用方式与Callable类似，但在返回结果时不一样，它返回的时实际结果可能没有生成，实际的结果可能会在另外的线程里面设置到DeferredResult中去。DeferredResult的这个特性对实现服务端推技术、订单过期时间处理、长轮询、模拟MQ的功能等高级应用非常重要。常见的使用场景：

1、如熟悉Apollo使用原理的同学，可能有了解，Apollo配置实时热更新便是基于DeferredResult实现配置变更通知的

2、如前端轮询订单支付状态，为减轻服务器压力，可改为长链接的形式，基于DeferredResult实现异步结果回调

关于DeferredResult的使用先来看一下官方的例子和说明：

上述示例中我们可以发现DeferredResult的调用并不一定在Spring MVC当中，它可以是别的线程。官方的解释也是如此：

In this case the return value will also be produced from a separate thread. However, that thread is not known to Spring MVC. For example the result may be produced in response to some external event such as a JMS message, a scheduled task, etc.

也就是说，DeferredResult返回的结果也可能是由MQ、定时任务或其他线程触发。来个实例：

第一个请求/hello，会先将deferredResult存起来，前端页面是一直等待（转圈）状态。直到发第二个请求：setHelloToAll，所有的相关页面才会有响应。

整个执行流程如下：

通过上述流程可以发现：利用DeferredResult可实现一些长连接的功能，比如当某个操作是异步时，可以先保存对应的DeferredResult对象，当异步通知回来时，再找到这个DeferredResult对象，在setResult处理结果即可。从而提高性能。

在SpringBoot中将一个方法声明为异步方法非常简单，只需两个注解即可@EnableAsync和@Async。其中@EnableAsync用于开启SpringBoot支持异步的功能，用在SpringBoot的启动类上。@Async用于方法上，标记该方法为异步处理方法。

需要注意的是@Async并不支持用于被@Configuration注解的类的方法上。同一个类中，一个方法调用另外一个有@Async的方法，注解也是不会生效的。

@EnableAsync的使用示例：

@Async的使用示例：

@Async注解的使用与Callable有类似之处，在默认情况下使用的都是SimpleAsyncTaskExecutor线程池，可参考Callable中的方式来自定义线程池。

下面通过一个实例来验证一下，启动类上使用@EnableAsync，然后定义Controller类：

定义Service及异步方法：

如果先注释掉@EnableAsync和@Async注解，即正常情况下的业务请求，打印日志为：

使用@EnableAsync和@Async注解时，打印日志如下：

通过日志的对比我们可以看出，使用了@Async的方法，会被当成一个子线程。所以，整个sendSms方法会在主线程执行完了之后执行。

今天我们来探讨下 spring 是如何完成这个异步功能的： spring 在扫描bean的时候会扫描方法上是否包含@async的注解，如果包含的，spring会为这个bean动态的生成一个子类，我们称之为代理类(?)， 代理类是继承我们所写的bean的，然后把代理类注入进来，那此时，在执行此方法的时候，会到代理类中，代理类判断了此方法需要异步执行，就不会调用父类 (我们原本写的bean)的对应方法。spring自己维护了一个队列，他会把需要执行的方法，放入队列中，等待线程池去读取这个队列，完成方法的执行， 从而完成了异步的功能。我们可以关注到再配置task的时候，是有参数让我们配置线程池的数量的。因为这种实现方法，所以在同一个类中的方法调用，添加@async注解是失效的！，原因是当你在同一个类中的时候，方法调用是在类体内执行的，spring无法截获这个方法调用。

那在深入一步，spring为我们提供了AOP，面向切面的功能。他的原理和异步注解的原理是类似的，spring在启动容器的时候，会扫描切面所定义的 类。在这些类被注入的时候，所注入的也是代理类，当你调用这些方法的时候，本质上是调用的代理类。通过代理类再去执行父类相对应的方法，那spring只 需要在调用之前和之后执行某段代码就完成了AOP的实现了！

所在的包不同：

通过所在的包，我们应该隐隐约约感到一些区别，比如@Async是位于scheduling包中，而WebAsyncTask和DeferredResult是用于Web（Spring MVC）的，而Callable是用于concurrent（并发）处理的。

对于Callable，通常用于Controller方法的异步请求，当然也可以用于替换Runable的方式。在方法的返回上与正常的方法有所区别：

而WebAsyncTask是对Callable的封装，提供了一些事件回调的处理，本质上区别不大。

DeferredResult使用方式与Callable类似，重点在于跨线程之间的通信。

@Async也是替换Runable的一种方式，可以代替我们自己创建线程。而且适用的范围更广，并不局限于Controller层，而可以是任何层的方法上。

当然，大家也可以从返回结果，异常处理等角度来分析一下，这里就不再展开了。

我们还可以自己造轮子，通过自定义线程池的工具类的方式，实现业务异步执行。

使用示例：

经过上述的分析探讨，大家应该对于常见异步处理有所了解，当熟悉这些基础理论，实战实例，使用方法及注意事项之后，在后续实际应用中，还需仔细探究其中实现细节，具体情况具体分析，研发过程需避免“拿来主义”，避免踩坑，敬畏线上的每一行代码。

附：参考链接：

1、zhuanlan.zhihu.com/p/146336940

2、zhuanlan.zhihu.com/p/99268715

3、juejin.cn/post/694312…

4、blog.csdn.net/wangdong567…