性能文章>扯下@EventListener这个注解的神秘面纱。>

扯下@EventListener这个注解的神秘面纱。原创

https://a.perfma.net/img/2382850
1年前
345106

你好呀,我是歪歪。

前段时间看到同事在项目里面使用了一个叫做 @EventLintener 的注解。

在这之前,我知道这个注解的用法和想要达到的目的,但是也仅限于此,其内部工作原理对我来说是一个黑盒,我完完全全不知道它怎么就实现了“监听”的效果。

现在既然已经出现在项目里面了,投入上生产上去使用了,所以我打算盘一下它,以免以后碰到问题的时候错过一个装逼的...

哦,不。

错过一个表现自己的机会。

Demo

首先,按照歪歪歪师傅的老规矩,第一步啥也别说,先搞一个 Demo 出来,没有 Demo 的源码解读,就像是吃面的时候没有大蒜,差点意思。

先铺垫一个背景吧。

假设现在的需求是用户注册成功之后给他发个短信,通知他一下。

正常来说,伪代码很简单:

boolean success = userRegister(user);
if(success){
    sendMsg("客官,你注册成功了哦。记得来玩儿~");
}

这代码能用,完全没有任何问题。但是,你仔细想,发短信通知这个动作按理来说,不应该和用户注册的行为“耦合”在一起,难道你短信发送的时候失败了,用户就不算注册成功吗?

上面的代码就是一个耦合性很强的代码。

怎么解耦呢?

应该是在用户注册成功之后,发布一个“有用户注册成功了”的事件:

boolean success = userRegister(user);
if(success){
    publicRegisterSuccessEvent(user);
}

然后有地方去监听这个事件,在监听事件的地方触发“短信发送”的动作。

这样的好处是后续假设不发短信了,要求发邮件,或者短信、邮件都要发送,诸如此类的需求变化,我们的用户注册流程的代码不需要进行任何变化,仅仅是在事件监听的地方搞事情就完事了。

这样就算是完成了两个动作的“解耦”。

怎么做呢?

我们可以基于 Spring 提供的 ApplicationListener 去做这个时间。

我的 Demo 里面用的 Spring 版本是 5.2.10。

这次的 Demo 也非常的简单,我们首先需要一个对象来封装事件相关的信息,比如我这里用户注册成功,肯定要关心的是 userName:

@Data
public class RegisterSuccessEvent {

    private String userName;

    public RegisterSuccessEvent(String userName) {
        this.userName = userName;
    }
}

我这里只是为了做 Demo,对象很简单,实际使用过程中,你需要什么字段就放进去就行。

然后需要一个事件的监听逻辑:

@Slf4j
@Component
public class RegisterEventListener {

    @EventListener
    public void handleNotifyEvent(RegisterSuccessEvent event) {
        log.info("监听到用户注册成功事件:" +
                "{},你注册成功了哦。记得来玩儿~", event.getUserName());
    }

}

接着,通过 Http 接口来进行事件发布:

@Resource
private ApplicationContext applicationContext;
@GetMapping("/publishEvent")
public void publishEvent() {
    applicationContext.publishEvent(new RegisterSuccessEvent("歪歪"));
}

最后把服务启动起来,调用一次:

输出正常,完事儿,这个 Demo 就算是搞定了,就只有十多行代码。

这么简单的 Demo 你都不想亲自动手去搭一个的话,想要靠肉眼学习的话,那么我只能说:

Debug

来,我问你,如果是你的话,就这几行代码,第一个断点你会打在哪里?

这没啥好犹豫的,肯定是选择打事件监听的这个地方:

然后直接就是一个发起调用,拿到调用栈再说:

通过观察调用栈发现,全是 Spring 的 event 包下的方法。

此时,我还是一头雾水的,完全不知道应该怎么去看,所以我只有先看第一个涉及到 Spring 源码的地方,也就是这个反射调用的地方:

org.springframework.context.event.ApplicationListenerMethodAdapter#doInvoke

通过观察这三个关键的参数,我们可以断定此时确实是通过反射在调用我们 Demo 里面的 RegisterEventListener 类的 handleNotifyEvent 方法,入参是 RegisterSuccessEvent 对象,其 userName 字段的值是“歪歪”:

此时,我的第一个问题就来了:Spring 是怎么知道要去触发我的这个方法的呢?

或者换个问法:handleNotifyEvent 这个我自己写的方法名称怎么就出现在这里了呢?

然后顺着这个 method 找过去一看:

哦,原来是当前类的一个字段,随便还看到了 beanName,也是其一个字段,对应着 Demo 的 RegisterEventListener。

到这里,第二个问题就随之而来了:既然关键字段都在当前类里面了,那么这个当前类,也就是 ApplicationListenerMethodAdapter 是什么时候冒出来的呢?

带着这个问题,继续往下查看调用栈,会看到这里的这个 listener 就是我们要找的这个“当前类”:

所以,我们的问题就变成了,这个 listener 是怎么来的?

然后你就会来到这个地方,把目光停在这个地方:

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

为什么会在这个地方停下来呢?

因为在这个方法里面,就是整个调用链中 listener 第一次出现的地方。

所以,第二个断点的位置,我们也找到了,就是这个地方:

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

但是,朋友们注意,我要但是了。

但是,当然把断点打在这个地方,重启服务准备调试的时候,你会发现重启的过程中就会停在断点处,而停下来的时候,你去调试会发现根本就不是你所关心的逻辑。

全是 Spring 启动过程中触发的一些框架的监听逻辑。比如应用启动事件,就会在断点处停下:

怎么办呢?

针对这种情况,有两个办法。

第一个是服务启动过程中,把断点停用,启动完成之后再次打开断点,然后触发调用。

idea 也提供了这样的功能,这个图标就是全局的断点启用和停用的图标:

这个方法在我们本次调试的过程中是行之有效的,但是假设如果以后你想要调试的代码,就是要在框架启动过程中调试的代码呢?

所以,我更想教你第二种方案:使用条件断点。

通过观察入参,我们可以看到 event 对象里面有个 payload 字段,里面放的就是我们 Demo 中的 RegisterSuccessEvent 对象:

那么,我们可不可以打上断点,然后让 idea 识别到是上述情况的时候,即有 RegisterSuccessEvent 对象的时候,才在断点处停下来呢?

当然是可以的,打条件断点就行。

在断点处右键,然后弹出框里面有个 Condition 输入框:

Condition,都认识吧,高考词汇,四级词汇了,抓紧时间背一背:

在 idea 的断点这里,它是“条件”的意思,带着个输入框,代表让你输入条件的意思。

另外,关于 Condition 还有一个短语,叫做 in good condition。

反应过来大概是“状况良好”的意思。

比如:我已出仓,in good condition。

再比如:Your hair is not in good condition。

就是说你头发状况不太好,需要注意一下。

扯远了,说回条件断点。

在这里,我们的条件是:event 对象里面的 payload 字段放的是我们 Demo 中的 RegisterSuccessEvent 对象时就停下来。

所以应该是这样的:

event instanceof PayloadApplicationEvent && (((PayloadApplicationEvent) event).payload instanceof RegisterSuccessEvent)

当我们这样设置完成之后,重启项目,你会发现重启过程非常丝滑,并没有在断点处停下来,说明我们的条件断点起作用了。

然后,我们再次发起调用,在断点处停下来了:

主要关注 134 行的 listener 是怎么来的。

当我们观察 getApplicationListeners 方法的时候,会发现这个方法它主要是在对 retrieverCache 这个缓存在搞事情。

这个缓存里面放的就是在项目启动过程中已经触发过的框架自带的 listener 对象:

调用的时候,如果能从缓存中拿到对应的 listener,则直接返回。而我们 Demo 中的自定义 listener 是第一次触发,所以肯定是没有的。

因此关键逻辑就在 retrieveApplicationListeners 方法里面:

org.springframework.context.event.AbstractApplicationEventMulticaster#retrieveApplicationListeners

这个方法里面的逻辑较多,我不会逐行解析。

只说一下这个关键的 for 循环:

这个 for 循环在干啥事呢?

就是循环当前所有的 listener,过滤出能处理当前这个事件的 listener。

可以看到当前一共有 20 个 listener,最后一个 listener 就是我们自定义的 registerEventListener:

每一个 listener 都经过一次 supportsEvent 方法判断:

supportsEvent(listener, eventType, sourceType)

这个方法,就是判断 listener 是否支持给定的事件:

因为我们知道当前的事件是我们发布的 RegisterSuccessEvent 对象。

对应到源码中,这里给定的事件,也就是 eventType 字段,对应的就是我们的 RegisterSuccessEvent 对象。

所以当循环到我们的 registerEventListener 的时候,在 supportsEventType 方法中,用 eventType 和 declaredEventTypes 做了一个对比,如果比上了,就说明当前的 listener 能处理这个 eventType。

前面说了 eventType 是 RegisterSuccessEvent 对象。

那么这个 declaredEventTypes 是个啥玩意呢?

declaredEventTypes 字段也在之前就出现过的 ApplicationListenerMethodAdapter 类里面。supportsEventType 方法也是这个类的方法:

而这个 declaredEventTypes,就是 RegisterSuccessEvent 对象:

这不就呼应上了吗?

所以,这个 for 循环结束之后,里面一定是有 registerEventListener的,因为它能处理当前的 RegisterSuccessEvent 这个事件。

但是你会发现循环结束之后 list 里面有两个元素,突然冒出来个 DelegatingApplicationListener 是什么鬼?

这个时候怎么办?

别去研究它,它不会影响我们的程序运行,所以可以先做个简单的记录,不要分心,要抓住主要矛盾。

经过前面的一顿分析,我们现在又可以回到这里了。

通过 debug 我们知道这个时候我们拿到的就是我们自定义的 listener 了:

从这个 listener 里面能拿到类名、方法名,从 event 中能拿到请求参数。

后续反射调用的过程,条件齐全,顺理成章的就完成了事件的发布。

看到这里,你细细回想一下,整个的调试过程,是不是一环扣一环。只要思路不乱,抓住主干,问题不大。

进一步思考

到这里,你是不是认为已经调试的差不多了?

自己已经知道了 Spring 自定义 listener 的大致工作原理了?

闭着眼睛想一想也就知道大概是一个什么流程了?

那么我问你一个问题:你回想一下我最最开始定位到反射这个地方的时候是怎么说的?

是不是给了你这一张图,说 beanName、method、declaredEventTypes 啥的都在 ApplicationListenerMethodAdapter 这个类里面?

请问:这些属性是什么时候设置到这个类里面的呢?

这个...

好像...

是不是确实没讲?

是的,所以说这部分我也得给你补上。

但是如果我不主动提,你是不是也想不起来呢,所以我也完全可以就写到这里就结束了。

我把这部分单独写一个小节就是提一下这个问题:如果你只是跟着网上的文章看,特别是源码解读或者方案设计类文章,只是看而不带着自己的思路,不自己亲自下手,其实很多问题你思考不全的,关键是看完以后你还会误以为你学全了。

现在我们看一下 ApplicationListenerMethodAdapter 这个类是咋来的。

我们不就是想看看 beanName 是啥时候和这个类扯上关系的嘛,很简单,刚刚才提到的条件断点又可以用起来了:

重启之后,在启动的过程中就会在构造方法中停下,于是我们又有一个调用栈了:

可以看到,在这个构造方法里面,就是在构建我们要寻找的 beanName、method、declaredEventTypes 这类字段。

而之所以会触发这个构造方法,是因为 Spring 容器在启动的过程中调用了下面这个方法:

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

在这个方法里面,会去遍历 beanNames,然后在 processBean 方法里面找到带有 @EventListener 注解的 bean:

在标号为 ① 地方找到这个 bean 具体是哪些方法标注了 @EventListener。

在标号为 ② 的地方去触发 ApplicationListenerMethodAdapter 类的构造方法,此时就可以把 beanName,代理目标类,代理方法通过参数传递过去。

在标号为 ③ 的地方,将这个 listener 加入到 Spring 的上下文中,后续触发的时候直接从这里获取即可。

那么 afterSingletonsInstantiated 这个方法是什么时候触发的呢?

还是看调用栈:

你即使再不熟悉 Spring,你至少也听说过容器启动过程中有一个 refresh 的动作吧?

就是这个地方:

这里,refreshContext,就是整个 SpringBoot 框架启动过程的核心方法中的一步。

就是在这个方法里面中,在服务启动的过程中,ApplicationListenerMethodAdapter 这个类和一个 beanName 为 registerEventListener 的类扯上了关系,为后续的事件发布的动作,埋好了伏笔。

细节

前面了解了关于 Spring 的事件发布机制主干代码的流程之后,相信你已经能从“容器启动时”和“请求发起时”这两个阶段进行了一个粗犷的说明了。

但是,注意,我又要“但是”了。

里面其实还有很多细节需要注意的,比如事件发布是一个串行化的过程。假设某个事件监听逻辑处理时间很长,那么势必会导致其他的事件监听出现等待的情况。

比如我搞两个事件监听逻辑,在其中一个的处理逻辑中睡眠 3s,模拟业务处理时间。发起调用之后,从日志输出时间上可以看出来,确实是串行化,确实是出现了等待的情况:

针对这个问题,我们前面讲源码关于获取到 listener 之后,其实有这样的一个逻辑:

这不就是线程池异步的逻辑吗?

只不过默认情况下是没有开启线程池的。

开始之后,日志就变成了这样:

那么怎么开启呢?

主干流程都给你说了个大概了,这些分支细节,就自己去研究吧。

再比如,@EventListener 注解里面还有这两个参数,我们是没有使用到的:

它应该怎么使用并且其到的作用是什么呢?

对应的源码是哪个部分呢?

这也是属于分支细节的部分,自己去研究吧

再再比如,前面讲到 ApplicationListenerMethodAdapter 这个类的时候:

你会发现它还有一个子类,点过去一看,它有一个叫做 ApplicationListenerMethodTransactionalAdapter 的儿子:

这个儿子的名字里面带着个 “Transactional”,你就知道这是和事务相关的东西了。

它里面有个叫做 TransactionalEventListener 的字段,它也是一个注解,里面对应着事务的多个不同阶段:

想都不用想,肯定是可以针对事务不同阶段进行事件监听。

这部分“儿子”的逻辑,是不是也可以去研究研究。

再再再比如,前面提到了 Spring 容器在启动的过程中调用了下面这个方法:

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

这个方法属于哪个类?

它属于 EventListenerMethodProcessor 这个类。

那么请问这个类是什么时候出现在 Spring 容器里面的呢?

这个...

好像...

是不是确实没讲?

是的,但是这个类在整个框架里面只有一次调用:

调试起来那不是手拿把掐的事情?

也可以去研究研究嘛,看着看着,不就慢慢的从 @EventLintener 这个小口子,把源码越撕越大了?

··············  END  ··············

👍

👍线BUGCPU100%

👍

👍

👍

线title

 

点赞收藏
分类:标签:
why技术
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
6
0