Springboot @Async 失效的坑
异步应用场景
为了提高接口的响应性能，当业务非常复杂的情况下，可以将一部分跟业务关联性不是特别强的逻辑进行异步处理。如日志记录、短信发送、增加积分等。通常而言会将此类业务逻辑通过异步的方式进行处理，从而加快接口的响应速度，常用的解决方案有：
- 使用JDK 自定义线程池 让代码异步执行
- 在springboot 中 使用@Async注解进行异步处理
- 使用中间件如mq 消息通知让下游异步消费 如RocketMQ、KAFKA
使用第一种方式，需要精通线程池运行原理，结合实际的业务场景对队列大小进行合理的设置。队列设置过大过小都会存在内存溢出的风险。
第三种方式是最合理的方式，它能够通过MQ进行削峰填谷，通过合理的参数配置，保证数据不会丢失。但是架构改动过大，对小型的单体应用来讲，工作量过大，成本过高。
在springboot 大行其道的情况下，考虑开发成本，以及项目时间关系选用第二种方式来解决代码异步执行的问题。
真实业务场景
线上问题
一个工单的分页列表，前端控制了每个列表最大的显示条数为100条。在业务流程中存在工单转移的操作，转移一笔工单至少包含以下几个重要的步骤：
- 新增工单处理日志，如什么时间点将工单转移给某人
- 修改工单当前处理人
- 发送企业微信给B端的跟进人(转移人)
- 发送im信息给C端的用户
由于公司采用微服务架构，因此每个业务模块拆分的很细，在上述步骤中需要从其他系统中通过rpc调用接口拿到需要的数据才能完成整个业务流程数据的拼装，如需要从crm系统拿到组织架构信息，获取转移人的组织架构、需要从udb用户中心获取转移人的企业微信昵称等。
因此在批量转移的时候，前端会出现调用超时的问题，原因是dubbo接口默认的超时时间是15秒，由于业务复杂，导致在15秒内执行不完业务逻辑。
解决方案
- 将sql处理改为批量执行，如新增处理日志 (batch insert)；修改当前工单，使用case when 的方式一次性修改完成(批量update)
- 将发送消息改成异步处理 加快前端接口的响应速度
- 让接口提供方提供批量查询的接口，避免rpc 循环调用在网络上的消耗
优化完成之后，接口的响应速度由15秒多，变成了1秒。但是过程中遇到坑了。特此记录一下
技术实现
优化过程
@Async 注解定义为可以放置在方法上和类上，当使用在类上表明类所有的方法都能异步执行。在Springboot中是需要在方法上加上该注解就可以完美的实现异步执行。
原始方法伪代码如下
/*** 原始代码 采用流水式的代码一步步实现 业务逻辑*/
public void doBusiness(Object args){//1. 新增工单处理日志，如什么时间点将工单转移给某人//2. 修改工单当前处理人//3. 发送企业微信给B端的跟进人(转移人)//4. 发送im信息给C端的用户
}
那么异步问题就很好处理了，只需要将方法抽离形成多个子方法, 每个方法执行自己的业务处理逻辑，然后再方法加上@Async注解不就ok了么，伪代码如下
public void doBusiness(Object args){//2. 修改工单当前处理人this.doAsyncBusiness();
}// 单独抽离一个异步执行的方法 加上@Async注解
@Async
private void doAsyncBusiness(Object args){//1. 新增工单处理日志，如什么时间点将工单转移给某人//3. 发送企业微信给B端的跟进人(转移人)//4. 发送im信息给C端的用户
}打完收工，重启应用，进行测试，然而并没有像预期中的那样，接口的响应速度还是15秒左右。接着排查原因，可以肯定的是@Async是可以提供异步方法执行。应该是我们使用方式不对导致。
@Async 限制
熟悉Springboot AOP的同学可能会发现更改后的代码存在明显的问题
- 首先AOP代理机制要求 被代理的方法必须是 public , private 方法不能被代理
- 其次AOP代理机制会生成一个代理类 执行代理方法 注意 this.doAsyncBusiness() 调用的是本对象的方法 ;
- 在启动类上加上@EnableAsync注解
综上所述，原因我们已经通过AOP代理的原理找到了。下面摘自官方文档的一段话：
- it must be applied to public methods only
- self-invocation – calling the async method from within the same class – won’t work
The reasons are simple – 「the method needs to be public」 so that it can be proxied. And 「self-invocation doesn’t work」 because it bypasses the proxy and calls the underlying method directly.