当前位置：首页 > news >正文

SpringBoot 事件发布监听机制使用、分析、注意点（一篇到位）

news 来源：原创 2024/5/8 8:10:58

前言

这一篇从应用角度来跟大伙讲讲这个 spring 事件监听机制，顺便涉及到那些我认为大家应该一块了解的，我也会展开说说。

文章内容（包括不限于）：

1. 对比观察者模式

2. 应用场景的分析

3. 事件的创建编码介绍

4. 事件如何发出

5. 事件如何被接收处理

6. 同步方式、异步方式的整合

7. 使用注解方式和不使用注解

8. 多事件监听器执行顺序的设置

9. 源码浅析

10. 一些跑题杂谈

ps：上面列的这些，在本文章里面没有严格的顺序，我控制不住自己的跑题。

我介绍码字的同时，就当作是跟大伙聊天一样，所以有些话可能比较小白文，不喜勿喷。

正文

~~第一开头我就想吐槽，~~

~~其实文章的标题是有误的，应该是 Spring的容器的事件发布监听机制。~~

但是为什么我要这样起标题呢，鉴于我最近一些日子去给一些学弟讲一些也是有关ssm的或者说是spring的一些知识，他们好像有点抵触这些他们认为的 ‘老知识’，反而我把PPT标题或者课题改一下，是springboot开头，他们会变得兴趣大一些。

我在想，要是想让初学者也能玩明白这个事件发布监听机制，我认为很有必要先去普及一下观察者模式，当然我也不会非常深入去介绍观察者模式（可能也没得有很深入的东西）

那么我就画一张图，先给大伙了解下观察者模式（看起来乱，但是井井有序）：

大家可以结合这段小白文描述去了解观察者模式：

1. 观察者和被观察者是 1 对多方式。（小华被好几个人盯着）

2. 观察者需要让被观察者知道自己是参与观察他的人。（小华其实提供了登记列表途径，小蓝、小黄、小橙其实都有通过这个途径留下了自己的联系号码 update方法）

3. 被观察者小华，有台大哥大手机（notify方法）专门打给这些观察者。（小华的业务方法里面会调用这个notify方法）

4. 大哥大从登记列表里面循环一个个地通知了小蓝、小黄、小橙 , 他们接到通知，就开始调用自己的业务方法进行处理。

看到这，再看一副更加简单的描述图，这一下子已经从深入到浅出了：

接下来，有了观察者设计模式的一定了解之后，我们直接再看一张浅出图，spring事件发布监听机制的图：

其实，大家一直都说的观察者设计模式，很多情况就是被叫做发布-订阅设计模式。

但是你说它们是不是完全一致嘛，不完全，但是实现的模式讲真是一致的。

一个主动变化的人，一个等待通知跟着做出变化的人。

而对于所谓的调度中心，只是把这两者的交流交互给抽离出来罢了。

甚至很多框架里面对于这个调度中心的设计实现都是隐藏的，我们甚至没有感觉到有这个调度中心的存在。

因为怎么去处理这两者的一来一回的微妙依赖关系，不同的人也许也是有不同的设计思路的。

（甚至我们理解玩观察者模式的流程细节，我们自己也可尝试地去实现我们自己的一个观察者模式/发布订阅模式，不基于java提供的观察者相关类，不基于spring提供的事件发布订阅等，自己可以做个小挑战，当然大牛已经设计封装出来的东西，肯定是非常优秀的了，有没有必要自己再重造轮子，大家心里有自己的答案）。

啰唆了很多，我们一起从业务示例场景去更近一步玩一下 spring的事件发布监听机制。

业务场景：

这是一个游戏公司，我们这个示例需求是有关于充值相关的增强用户体验的需求。

玩家给游戏账号充值买礼包了，我们需要在充钱成功后，

通过短信给玩家的手机发送一个通知，给他通知一下，让他知道钱花了。

产品说你快去设计一下做吧。

开发小明找到原先的充值方法，在后面加了个发短信

写完，提测，上线：

    public void recharge(){

        //充值氪金处理............

        //然后
        sendSms(String phone);
    }

不到2天，玩家开始反馈，短信很多收不到，被手机拦截了，麻烦，但是又想知道充值的信息；

账号是绑定过邮箱的，能不能也发个邮件。

产品：加个发邮件。

开发小明又去改代码了，找到了充值方法里面在发短信后面，加了个发邮件。

开发写完，提测，上线：

    public void recharge(){

        //充值氪金处理............

        //然后
        sendSms(String phone);
        sendEmail(String email);
    }

第二天，产品又说，玩家充钱欲望不够，我们给他们说了，买不同礼包，赠送的积分不同，越贵的，送的积分多多。积分后面可以兑换小礼品。

产品：加积分！

开发小明又去改代码了，找到了充值方法里面在发邮件后面又加了个加积分。

    public void recharge(){

        //充值氪金处理............

        //然后
        sendSms(String phone);
        sendEmail(String email);
        addScore(Integer accountId);
    }

上面说的场景是非常常见的，需求出现一步步叠加是很正常的。

开发因为需求变化，频繁改代码，其实也是很正常的。

但是怎么改，这一点，是讲究的，是根据我们设计的考虑而去决定改动的方式的。

上面这个业务场景例子，可以看到，小明一直去改。

但是改在哪？改的是充值的方法。

充值变了吗？其实没变。变的是充值后的一些业务。

所以本身小明在写设计这个充值接口的时候，把充值后的一些额外业务都混在一块，

已经有违单一职责的原则了。

而频繁去改充值接口，因为别的业务去改充值接口方法，

那么也有违充值接口方法的开闭原则。

而且，这还好全是小明自己一个人写的代码，如果说不单是小明一个人，充值接口是小花写的。

你改自己的充值后的需求，天天改人家小花的充值接口实现代码。

小花都天天提心吊胆的，生怕被你改多了几行，每次上线发版，项目经理说，这次有关的版本上线有关人员需要留下来，有负责充值的小花，负责充值后提升用户体验的小明。

你说，小花什么感受，直接就EMO了。

这时候，可能有很多看官已经想到了解决方案了，就是让小明写一个充值后调用的方法（里面囊括发短信、发邮件、加积分等等甚至应对以后的扩展），小花那边充值之后只需要调用一下这个方法即可。

也就是：

    public void recharge(){
        //充值氪金处理............

        //然后
        afterRecharge();
    }


    public void afterRecharge(){
        
        sendSms(String phone);
        sendEmail(String email);
        addScore(Integer accountId);
    }

乍一看好像ok的，但是其实还是未能完全解耦。

如果业务扩展起来了，

小明认为发短信、发邮箱属于调用消息中心的方法，应该分出一个sendNotice方法；

然后加积分、加经验等游戏账号体系相关的，应该分出一个 xxx 方法。

这两部分已经分开设计了，小花只需要分别调用就可以，没必要在外面套一层。因为这两个方法之间也不存在任何相关连。短信不发，积分也是要加的。

但是小花可能就不同意了，不止小花，可能调用 afterRecharge 方法的人，还有小曼，小路，小玲等等。这么多人，很难一个个让他们改。

可能例子举的比较极端，放大了问题点。

其实这就是解耦彻底的问题。如果我们使用事件发布监听机制，可以更优美地去应对这些场景。

事件发布监听机制：

充值完，发布一个事件。

小明自己去监听这个充值完的事件，写自己的订阅者，不管是写一个还是多个，可以自己拿捏。

单独发短信一个监听器 A ；

单独发邮件一个监听器 B；

单独处理加积分等一个监听器 C；

甚至把 AB 整合一个监听器， C单独一个。

可以说是开发自由，后面产品怎么提这些充值后的业务需求，小花都不几乎不用参与。

就找小明就行，小明也舒服。

因为他实现了以增量的设计方式去应对这些变化多端的需求。

ok，事不宜迟，啰唆了这么多，我们看看spring事件发布订阅的代码的简单实现：

（如果你是为了想找实现例子的，看到这估计也不容易，大多数应该早就退出了）

1. 创建充值事件，充值成功就发布这个事件：

RechargeChangeEvent.java

里面包含充值的礼包活动id ；

包含用户游戏账号一些相关的信息（举例就随便写个User类了）；

/**
 * @Author JCccc
 * @Description
 * @Date 2020/10/12 9:08
 */
public class RechargeChangeEvent extends ApplicationEvent {

    private Integer giftActivityId;

    private User user;


    public RechargeChangeEvent(Object source, Integer giftActivityId,User user) {
        super(source);
        this.giftActivityId = giftActivityId;
        this.user = user;
    }

    public Integer getGiftActivityId() {
        return giftActivityId;
    }

    public void setGiftActivityId(Integer giftActivityId) {
        this.giftActivityId = giftActivityId;
    }

    public User getUser() {
        return user;
    }

    public void setUser(User user) {
        this.user = user;
    }
}

稍作讲解：

2. 发短信监听器：

SmsListener.java

/**
 * @Author JCccc
 * @Description
 * @Date 2020/10/12 9:08
 */
@Component
public class SmsListener implements SmsService, ApplicationListener<RechargeChangeEvent> {
    @Override
    public void sendSms(String phone) {
        System.out.println("发送短信 成功");
    }

    @Override
    public void onApplicationEvent(RechargeChangeEvent event) {
        System.out.println("-------------------------------");
        Integer giftActivityId = event.getGiftActivityId();

        System.out.println("参与礼包活动id "+giftActivityId+" ，处理短信相关业务 , 获取短信签名等。。。。");

        String phone = event.getUser().getPhone();
        sendSms(phone);

    }
}

稍作讲解：

ps： @Component 记得别忘记了，这实现的，继承的用的都是spring里面的。我们自己的自定义监听器那肯定也得丢里头了。当然图里面的多实现不是一定要这么写的，如果你的监听业务非常特殊，完全可以单独封装一个方法写在对应监听器里面。

3. 发邮件监听器

EmailListener.java

@Component
public class EmailListener implements EmailService, ApplicationListener<RechargeChangeEvent> {
    @Override
    public void sendEmail(String email) {
        System.out.println("发送邮件 成功");
    }

  
    @Override
    public void onApplicationEvent(RechargeChangeEvent event) {
        System.out.println("-------------------------------");

        try {
            sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Integer giftActivityId = event.getGiftActivityId();
        System.out.println("参与礼包活动id "+giftActivityId+" ，处理邮件相关业务 , 进行 A BC等。。。。");
        String email = event.getUser().getEmail();
        sendEmail(email);

    }
}

4. 扩展一些额外的监听器，例如加积分、加经验等等。

上面两个都是采用的代码实现方式，实现了 ApplicationListener ，那么我们也同时搞点不一样的，我们用注解 @EventListener 玩一下。

可以看到用注解，代码实现非常简洁，明名上面也不需要强制重写 onApplicationEvent ，

直接自己明名，更加贴切合理，通过事件来给注解标识一下，监听器对应的哪个事件即可。

我支持注解！从简！

@Component
public class XxxxxListener {

    @EventListener
    public void doXxxxx(RechargeChangeEvent event) {
        System.out.println("-------------------------------");
        Integer giftActivityId = event.getGiftActivityId();
        User user = event.getUser();
        System.out.println("处理Xxxxx业务");
        System.out.println("Xxxxx 成功");
    }
    
}

5. 最后写个模拟接口实现方法，也就是充值方法，里面会发布一个充值事件：

@Service
public class RechargeServiceImpl implements RechargeService {
    @Autowired
    private ApplicationContext applicationContext;

    @Override
    public void recharge(Integer giftActivityId, User user) {
        System.out.println("给用户"+user.getPhone() +"充值成功；使用的充值礼包系列id :"+giftActivityId);
        // 发布事件通知
        applicationContext.publishEvent(new RechargeChangeEvent(this,giftActivityId,user));
    }
}

6.我们也模拟一个接口，调用充值方法 :

7. 使用postman调用一下，看看效果：

可以看到打印顺序，监听器里面的相关代码都成功执行：

好了，spring的事件发布监听机制的一些使用，到这里也是讲完了。

但是还没完！

大家注意到我的打印输出的截图没？

1. 发邮件那么久，还真等这么久。

为什么先发邮件，我能先发短信吗？我能先加积分么？大家都是监听器，凭什么你先，我就想要固定哪个先，可以？

2 .再看看我如果在发邮件那里抛个异常：

可以看到，这spring默认的事件发布监听，是同步机制，一个出错，后面跟着泡汤！

出现了两个问题（使用需求）：

1. 自定义监听器监听到事件之后，执行的顺序 .

2. 默认同步要会用，但是我们也想用异步 .

解决第一个问题顺序问题：

我们把原先自定义继承的监听器 ApplicationListener<RechargeChangeEvent> 换成 SmartApplicationListener ：

具体代码示例， EmailListener.java ：

@Component
public class EmailListener implements EmailService, SmartApplicationListener{
    @Override
    public void sendEmail(String email) {
        System.out.println("发送邮件 成功");
    }
    @Override
    public boolean supportsEventType(Class<? extends ApplicationEvent> eventType){
        return eventType == RechargeChangeEvent.class;
    }

    @Override
    public boolean supportsSourceType(Class<?> sourceType){
        return true;
    }
    @Override
    public int getOrder(){
        return -1;
    }

    @Override
    public void onApplicationEvent(ApplicationEvent event){
        RechargeChangeEvent rechargeChangeEvent= (RechargeChangeEvent) event;
        System.out.println("-------------------------------");
        try {
            sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Integer giftActivityId = rechargeChangeEvent.getGiftActivityId();
        System.out.println("参与礼包活动id "+giftActivityId+" ，处理邮件相关业务 , 进行 A BC等。。。。");
        String email = rechargeChangeEvent.getUser().getEmail();
        sendEmail(email);
        System.out.println("监听到用户注册，给新用户发送首条站内短消息" + event.toString());
    }

}

可以看到有一个 getOrder 方法，邮件监听器我们设置的是 -1 ；

同样，SmsListener.java 也改成使用 SmartApplicationListener ：

@Component
public class SmsListener implements SmsService, SmartApplicationListener {
    @Override
    public void sendSms(String phone) {
        System.out.println("发送短信 成功");
    }
    @Override
    public boolean supportsEventType(Class<? extends ApplicationEvent> eventType){
        return eventType == RechargeChangeEvent.class;
    }
    @Override
    public boolean supportsSourceType(Class<?> sourceType){
        return true;
    }
    
    @Override
    public int getOrder(){
        return -2;
    }

    @Override
    public void onApplicationEvent(ApplicationEvent event){
        RechargeChangeEvent rechargeChangeEvent= (RechargeChangeEvent) event;
        System.out.println("-------------------------------");
        Integer giftActivityId = rechargeChangeEvent.getGiftActivityId();
        System.out.println("参与礼包活动id "+giftActivityId+" ，处理短信相关业务 , 获取短信签名等。。。。");
        String phone = rechargeChangeEvent.getUser().getPhone();
        sendSms(phone);
    }

}

getOrder 方法，我们设置的是 -2 ；

这个order ，谁数值小就执行顺序排越前面。

ok，我们执行一下，按照我们设置的顺序，发短信监听器是 -2 ，应该先执行：

顺序的问题我们已经解决了，但是有没有觉得改动好大，完全换了一个监听器，然后还重写好几个方法，很麻烦。

所以我们来用第二种方式解决，使用注解 @Order() 和 @EventListener ：

注解的方式永远是极简的，强烈推荐！

看看极简使用注解是怎么玩的 :

可以看到，邮件监听设置的顺序是 -10 ，短信是 -5 ：

解决第二个问题异步问题：

其实非常非常简单，基于注解方式，我们想要监听器都是多线程异步执行，我们只需要再叠加使用一个注解 @Async ，就像这样：

ps ：对于异步注解使用还没了解过的，可以先看看这篇 ,因为使用上是由一些注意点的SpringBoot 最简单的使用异步线程案例 @Async_默默不代表沉默-CSDN博客

这样我们启动一下：

这时候会出现一个关于代理的错误：

Either pull the method up to an interface or switch to CGLIB proxies by enforcing proxy-target-class mode in your configuration.

这里又要扯远了，其实是因为我们使用注解 @Async 导致的。其实在使用一些其他注解也会有遇到这种情况。

可以看到我们的代码写的情况：

EmailService 接口的实现类是 EmailListener ；

然后deal方法加了注解方法 EventListener和Async 注解的方法；

但是其实EmailService 接口里面是没这个方法的。

此时 EmailListener 被spring使用jdk代码方式生成的类，在收集注解相关的方法时，是去类的接口中寻找deal方法，找不到，所以就报错了。

在此，分析问题先打住，有结论，解决思路有3小种：

1.我们这个监听器就不要实现接口了。

2. 我们把这个被注解标记的方法 deal 也变成接口里面有的。

3. 监听器这几个类的代理方式变成CGLIB ，这样代理的类里面是能找到方法的。

上面三种方式好像都可以。

实践：

1.我们这个监听器就不要实现接口了：

可以看看每次初始化的时候，spring帮我们选择的代理方式（用到注解、aop的类）：

（这种情况都已经不实现接口，也只能是CGLIB代理了）

这种情形，我们把项目运行起来，调一下模拟接口，可以看到异步调用成功：

所以这种方式也是成功可行的！

2.我们把这个被注解标记的方法 deal 也变成接口里面有的

这样就明目张胆的的符合规矩了，所以运行发现成功了，我们的三个监听器都是异步的了：

特意在发短信的监听处理方法里面跑错，并不会影响其他监听器方法，异步线程机制执行：

所以这种方式也是成功可行的！

3. 保持实现接口的方式，直接就按照错误提示，我就用 CGLIB代理方式去生成监听器的代理类，不就解决了么：

其实这个@Async也提供了这种手段，也就是开启 proxyTargetClass，在被初始化收集时，生成的代理类会采取CGLIB方式。

其实就是因为我们想通过这种方式使用异步，然后@Async 使用时，用到了 @EnableAsync ，

而@EnableAsync 里面的代理方式 proxyTargetClass默认是false ，就是导致代理方式改成了JDK代理，然后就出现我们的报错。

所以我们要去解决，只需要设置为true。

可以看源码：

指示是否创建基于子类（CGLIB）的代理，而不是到标准的基于Java接口的代理。

仅当{@link#mode}设置为{@link AdviceMode#PROXY}时适用。

默认值为 false。

注意，将此属性设置为 true 将影响所有 Spring管理的bean需要代理，而不仅仅是那些用@Async标记的bean。

例如，使用Spring的@Transactional注释标记的其他bean将同时升级到子类代理。这种方法没有任何好处在实践中产生负面影响，除非有人明确期望一种类型的代理。

运行项目，可以看到成功使用CGLIB代理方式：