前言

这一篇从应用角度来跟大伙讲讲这个 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);
    }
}