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

系统管理员 2024-03-24 17:30 59阅读 0赞

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

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

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

哦，不。

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

### 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("歪歪"));
    }
    复制代码

最后把服务启动起来，调用一次：

![format_png][]

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

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

![format_png 1][]

### Debug ###

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

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

![format_png 2][]

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

![format_png 3][]

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

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

> org.springframework.context.event.ApplicationListenerMethodAdapter\#doInvoke

![format_png 4][]

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

![format_png 5][]

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

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

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

![format_png 6][]

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

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

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

![format_png 7][]

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

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

> org.springframework.context.event.SimpleApplicationEventMulticaster\#multicastEvent

![format_png 8][]

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

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

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

> org.springframework.context.event.SimpleApplicationEventMulticaster\#multicastEvent

![format_png 9][]

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

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

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

![format_png 10][]

怎么办呢？

![format_png 11][]

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

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

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

![format_png 12][]

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

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

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

![format_png 13][]

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

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

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

![format_png 14][]

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

![format_png 15][]

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

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

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

比如：我已出仓，in good condition。

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

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

![format_png 16][]

扯远了，说回条件断点。

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

所以应该是这样的：

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

![format_png 17][]

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

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

![format_png 18][]

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

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

![format_png 19][]

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

![format_png 20][]

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

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

> org.springframework.context.event.AbstractApplicationEventMulticaster\#retrieveApplicationListeners

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

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

![format_png 21][]

这个 for 循环在干啥事呢？

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

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

![format_png 22][]

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

> supportsEvent(listener, eventType, sourceType)

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

![format_png 23][]

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

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

![format_png 24][]

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

前面说了 eventType 是 RegisterSuccessEvent 对象。

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

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

![format_png 25][]

而这个 declaredEventTypes，就是 RegisterSuccessEvent 对象：

![format_png 26][]

这不就呼应上了吗？

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

![format_png 27][]

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

这个时候怎么办？

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

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

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

![format_png 28][]

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

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

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

### 进一步思考 ###

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

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

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

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

![format_png 29][]

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

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

![format_png 30][]

这个...

好像...

是不是确实没讲？

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

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

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

![format_png 31][]

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

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

![format_png 32][]

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

![format_png 33][]

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

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

> org.springframework.context.event.EventListenerMethodProcessor\#afterSingletonsInstantiated

![format_png 34][]

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

![format_png 35][]

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

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

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

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

还是看调用栈：

![format_png 36][]

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

就是这个地方：

![format_png 37][]

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

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

### 细节 ###

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

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

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

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

![format_png 38][]

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

![format_png 39][]

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

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

开始之后，日志就变成了这样：

![format_png 40][]

那么怎么开启呢？

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

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

![format_png 41][]

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

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

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

再再比如，前面讲到 ApplicationListenerMethodAdapter 这个类的时候：

![format_png 42][]

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

![format_png 43][]

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

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

![format_png 44][]

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

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

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

> org.springframework.context.event.EventListenerMethodProcessor\#afterSingletonsInstantiated

![format_png 45][]

这个方法属于哪个类？

它属于 EventListenerMethodProcessor 这个类。

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

![format_png 46][]

这个...

好像...

是不是确实没讲？

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

![format_png 47][]

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

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

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/6ec203dcaee645799b660a4a73bc0eae.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5561473a33db458e92b9def19f765a4a.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/706f1c09461b468bbc685c2be15b99b6.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/0e1a79550cb442569942e297ce391158.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/db6abbb1e8c645cd83d32d2099f91052.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/961d5cbff33f45949a5e91df6a3f62c5.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b2a4f575af2c40259a0e6a2ad481a8c3.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/aeffd81bc53a4de58f21a8777a099f25.png
[format_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e65d2676a8f940ffb5adc08c261212b9.png
[format_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f84dad9c56584933b28458edc293ce81.png
[format_png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8331023bd9984e99a6a04f30e22fff5d.png
[format_png 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a15478a346b641259b3b1f7dfcc7432d.png
[format_png 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/54c784afbd8d498ca0259f97965f0c96.png
[format_png 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/67dbc9d3eeec424383b53f3b994e07dd.png
[format_png 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1c72936f1ca341419836d4e69d164eae.png
[format_png 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/4a63aa539d3343d39a95dca213249a55.png
[format_png 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8ebd7b359f314be4ae5f09805feb45a8.png
[format_png 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/4edfedb9383f4bd2b09024c23bedfa86.png
[format_png 18]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ed597e697ed04944b1e10a9265c5975f.png
[format_png 19]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/7f6e2c30fea646b1849f492439868595.png
[format_png 20]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/176e9f0ff4864449a73d20be9b15fda3.png
[format_png 21]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/158dc296a912453a9d8ec6c56d724bca.png
[format_png 22]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1f1182d28fb64aa5b2cb1b61a9c28ea1.png
[format_png 23]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/708098a7cc414544aa4957f3a07f9b66.png
[format_png 24]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f198610f3e244bf493b832692360a7d2.png
[format_png 25]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b5840d08100643a694e8b5d420eebc2a.png
[format_png 26]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/b5e344afd4ef4f7184f98269c737cd02.png
[format_png 27]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/641b28efc89b4ae282a9c636108751ac.png
[format_png 28]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ec97f7ef4e22488ab43a4b6fe9e94167.png
[format_png 29]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/6d3119ac2bb74255bd90a390f6290748.png
[format_png 30]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8133d0c2024b43b2ae4efb6f15b04002.png
[format_png 31]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1ac798c4b18946379b892ef8c75df86f.png
[format_png 32]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9e066e29197c458c8ed4a31b2205ffc7.png
[format_png 33]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f1ac586d114d4d88ab9ee6241193102b.png
[format_png 34]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1a11954177054d74b1493ce46e5d8f93.png
[format_png 35]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/0e255676e4694be294202e8a6a319bad.png
[format_png 36]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/7032042133d045a4a11c409992221b59.png
[format_png 37]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9496908d7f8c4d36aaed235dcf92f251.png
[format_png 38]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a6f63688676b4a93b896a0287618e4b3.png
[format_png 39]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/811c13fed6ee4f8d800c91ef5b7bc09f.png
[format_png 40]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/2049dc3983374be9ad894190f4290c00.png
[format_png 41]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/598bab051de548ef9ac8766bb53d5c33.png
[format_png 42]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/07347c56bb884dc58ce7f46d7c6440b9.png
[format_png 43]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/2da2e65f634340d9824b35e71fe8d62c.png
[format_png 44]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/d1d65f97a3034550a350c89a91a79f7d.png
[format_png 45]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/100fec1b1fca4c60af4dcd32459af870.png
[format_png 46]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/48629762c0194b2eb7707311484a2fc9.png
[format_png 47]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/d803151ec1464650bf0bc31fa26eb8a7.png