事件机制(Event)是spring的重要功能之一。本文将从该功能的用法/和监听器的关系/应用的设计模式/源码讲解等几个方面，由浅入深做全方位讲解。 虽然是Spring的重要功能之一，但在大部分人的日常开发中，却很少直接应用该功能。 一句话概括用法场景：一个地方发出个通知，很多其他地方能收到通知并作出相应的动作。
后面的Demo以一个简单的Springboot项目为基础（文中也会贴出重要代码）。项目路径
在事件机制中有以下几个重要概念：
事件事件发布者（一个）事件监听者（多个）事件
package com.yc.blog.springboot.event.demo1; import org.springframework.context.ApplicationEvent; /** * 事件 */ public class MyEvent1 extends ApplicationEvent { private static final long serialVersionUID = 1L; /** * 自定义事件消息内容 */ private String message; /** * 为什么要这么写构造方法？ * 因为父类没有默认构造器，子类必须手动调用父类的那个构造器ApplicationEvent(Object source) * @param source * @param message */ public MyEvent1(Object source, String message) { super(source); this.message = message; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } }事件发布者
/** * 发布者 * 可在spring的任意位置注入，用来发布事件 * 也可以使用上下文容器ConfigurableApplicationContext来发布事件（因为它也继承了ApplicationEventPublisher） */ @Autowired private ApplicationEventPublisher applicationEventPublisher; @Test public void publish1() { System.out.println("----发布1开始-------"); MyEvent1 event = new MyEvent1(this, "新消息1"); applicationEventPublisher.publishEvent(event);//发布者发布消息 System.out.println("----发布1完成-------"); }事件监听者
package com.yc.blog.springboot.event.demo1; import org.springframework.context.ApplicationListener; import org.springframework.stereotype.Component; /** * 监听者 * 实现ApplicationListener接口 * */ @Component public class Listener1 implements ApplicationListener<MyEvent1> { @Override public void onApplicationEvent(MyEvent1 event) { System.out.println("Listener1 收到事件通知：" + event.getMessage()); //do something } }代码和概念一一对应，比较好理解，具体的细节先不管，跑起来看看效果。
... ----发布1开始------- Listener1 收到事件通知：新消息1 Listener2 收到事件通知：新消息1 ----发布1完成------- ...应用在事件机制的三个概念中的监听者身上，下面看用法
package com.yc.blog.springboot.event.demo1; import org.springframework.context.event.EventListener; import org.springframework.stereotype.Component; /** * 使用@EventListener实现监听者 */ @Component public class Listener3 { @EventListener public void listenerMyEvent1(MyEvent1 event) { System.out.println("Listener3 收到事件通知：" + event.getMessage()); //do something } }执行结果
----发布1开始------- Listener3 收到事件通知：新消息1 Listener1 收到事件通知：新消息1 Listener2 收到事件通知：新消息1 ----发布1完成-------该注解作用在方法上，跟前面普通监听者写法一样，方法参数列表里是要监听的事件类型。 在事件驱动编程中，监听者可能数量众多，有注解将会大大简化开发。 而且之前的写法一个类只能监听一个事件，有了注解，我们可以在一个类中写多个方法，监听多个事件，如下所示
/** * 学生监听多种事件，并作出响应 */ @Component public class Student { /** * 监听上课铃声 * @param event1 */ @EventListener public void listenSchoolBell(MyEvent1 event1) { System.out.println("上课铃响了，我要去上课..."); //do something } /** * 监听老师提问 * @param event2 */ @EventListener public void listenTeacherAskMe(MyEvent1 event2) { System.out.println("老师提问了，我要起立回答问题..."); //do something } }如上面定义的学生类，可以监听上课铃声，可以监听老师提问…，通过监听多种事件，让这个类更加符合java编程的“面向对象”思想。
想一个问题：发布一个事件，可能会有一堆的监听者，假如其中一个监听者出现异常，方法内部迟迟无法执行完，会对整个事件的发布有影响吗？看示例及结果
/** * 异常监听者 */ @Component public class Listener4 { @EventListener public void listenerMyEvent1(MyEvent1 event) { System.out.println("Listener4 收到事件通知：" + event.getMessage()); try { Thread.sleep(30000);//睡眠30秒，表示某个监听者执行时间过长 } catch (InterruptedException e) { e.printStackTrace(); } //do something System.out.println("----Listener4--over"); } }执行结果:在三十秒内，会一致阻塞在如下的状态
----发布1开始------- Listener3 收到事件通知：新消息1 Listener4 收到事件通知：新消息1由此我们可以大胆推断：事件发布是一个一个监听者的顺序执行，其中任意一个监听者出现执行缓慢或阻塞，都会导致整个事件发布受阻（后面我们会者源码中验证这个推断）。 就像一个明星不能因为其中粉丝的特殊情况改变自己的行程一样，我们的事件发布也不能因为某些不可预知的“特例监听者”导致整个事件发布受影响。 异步监听就可以解决这个问题，并且应用起来很简单，只需要加一两个注解
应用在“可能出现意外”的事件监听者方法上，如下所示
/** * 异常监听者 */ @Component public class Listener4 { @Async @EventListener public void listenerMyEvent1(MyEvent1 event) { System.out.println("Listener4 收到事件通知：" + event.getMessage()); try { Thread.sleep(30000);//睡眠30秒，表示某个监听者执行时间过长 } catch (InterruptedException e) { e.printStackTrace(); } //do something System.out.println("----Listener4--over"); } }在此之前，还需要加上@EnableAsync注解 @EnableAsync是应用在整个项目的配置，只需要写一次即可，表示该项目中允许使用@Async注解，如下所示
@EnableAsync @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class}) public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }再执行事件发布
----发布1开始------- Listener3 收到事件通知：新消息1 Listener1 收到事件通知：新消息1 Listener2 收到事件通知：新消息1 ----发布1完成------- Listener4 收到事件通知：新消息1 ----Listener4--over事件发布照常执行，并没有因为出现“异常的事件监听者”而阻塞后面的其他监听者。
为什么前面我们说“应用在可能出异常”的事件监听者方法上，而不是全都加上异步注解呢？因为资源占用，每使用一个异步方法，整个系统就多增加一个线程，而且在执行完之后并不会自动销毁，那些我们写的时候就确定不可能出现阻塞的监听器就可以不用加，当然 最好是使用线程池。具体用法及讲解请见博客“Spring中的@Async用法及应用场景”（这两个注解并非专门用来配合事件机制使用的）
一开始我们也讲了，实际生产中很少直接使用事件机制。而是间接的应用比较多，我们平时总能在web开发中听到监听器的说法（和过滤器还经常混淆），这里的监听器和前面的“监听者”是不是有关联呢，答案是肯定的。 打开定义事件的父类ApplicationEvent，使用IDE看一下该类的所有子类（涂掉的是我们自己定义的事件） 这里显示的都是Spring自带的事件，是我们可以直接进行监听的事件，看看有没有自己熟悉的类。下面以其中的相对比较常见的RequestHandleEvent为例，看看如何使用Spring提供的“监听器”。
功能：在SpringMvc收到请求时，会触发一个事件，我们可以通过监听该事件捕捉到用户每个发来的rququest请求，下面是个Demo，用来监听这种事件
/** * 监听RequestHandledEvent事件 */ @Component public class Listener5 { @EventListener public void listenerMyEvent1(RequestHandledEvent event) { System.out.println("Listener5 收到事件通知：" + event.getShortDescription()); //do something } }启动springboot，访问http://localhost:8080/project/test2，执行结果
---------test2-------- Listener5 收到事件通知：url=[/project/test2]; client=[0:0:0:0:0:0:0:1]; session=[null]; user=[null];可见，spring给提供的事件，监听方式和我们自己写的一样（本质都是一样的）。这个监听器就实现了类似于“request过滤器”的效果。上面列举的其他spring内部事件用法也都是如此，一些常用的功能描述如下
事件名称功能描述RequestHandledEventrequest请求事件ContextClosedEvent容器关闭事件ContextStartedEvent容器启动事件ContextStoppedEvent容器停止事件说到这里，也行会有人有些晕了。感觉在其他地方见过类似的监听器，但似乎和上面讲的有点区别。 那是因为你看到是servlet的监听器（或者说是Tomcat的监听器），详情请见spring/tomcat的过滤器监听器区别。
像Spring这样的优秀开源软件都会应用很多设计模式及编程思想。事件机制就是一个很好的例子。“事件驱动编程”本身就是一个很火的概念，Spring的事件机制就是“事件驱动编程”思想的应用。而这种思想更抽象的说法叫“观察者模式”或者叫“监听者模式” /“发布-订阅模式”（和观察者模式有细微差别：发布者和订阅者都不需要知道对方的存在）
更详细的概念解释及示例，请看观察者模式（Observer模式）详解
定义目标主题Subject(观察模式的运作中心)
/** * 目标主题(观察模式的运作中心) */ public interface Subject { /** * 增加观察者 * @param observer */ void addObserver(Observer observer); /** * 删除观察者 * @param observer */ void removeObserver(Observer observer); /** * 通知观察者 */ void inform(); }定义观察者Observer
/** * 观察者 */ public interface Observer { /** * 观察者在事件发生时的响应 */ void todo(); }那目标主题是怎么通知到每个观察者的呢。这里并没有什么高深的技术，就是把遍历目标主题里注册的全部观察者，调用他们的todo()方法。也就是说，所谓观察者在模式中是“被动观察”的，下面是目标主题的实现类
public class SubjectImpl implements Subject { private List<Observer> observerList = new ArrayList<Observer>(); @Override public void addObserver(Observer observer) { observerList.add(observer); } @Override public void removeObserver(Observer observer) { observerList.remove(observer); } @Override public void inform() { System.out.println("事件触发..."); for (Observer observer : observerList) { observer.todo(); } } }其他示例代码就略过(详细请看demo3)，直接看执行结果
事件触发... ------观察者1响应事件------ ------观察者2响应事件------既然事件机制是一种观察者模式的实现，那么对照一下概念：
观察者模式spring事件机制观察者(Observer)监听者(Listener)目标主题(Subject)EventMulticaster(事件广播器)-Event(事件)小结：
Observer对应Listener，这个比较好理解。事件机制中的Event是spring新增的抽象概念（更准确的说是“事件驱动编程”里抽象出来的概念）。事件机制中的“发布者”其实只是一个事件触发点，并不在观察者模式的定义里。从Subject所包含的核心逻辑就验证里前面的猜想：监听者者是一个一个顺序执行的。而观察者模式里的核心Subject是spring给我实现好的。下面我们通过源码，看一下Spring给实现好的Subject。前面说的EventMulticaster(事件广播器)在spring中实际叫ApplicationEventMulticaster ，下面是它的接口方法（之所先看接口，是因为接口是spring的骨架，定义了spring的原始设计想法，后面的抽象方法、具体实现都比较复杂，但都只是对接口的填充而已）
是不是和我们定义的Subject很像，虽然这里有7个方法，但归结起来还是那两个需求(3个方法)：
增删维护观察者: addxxx, removexxx通知观察者: multicastEvent(对应上面我们写的todo()方法)看一下这个接口的注释说明
Interface to be implemented by objects that can manage a number of ApplicationListener objects and publish events to them. 这是一个这样的接口：它用来管理一堆监听者对象并发布事件给他们
通过前面介绍事件广播器的几个功能，大致可以猜到Spring为我们做了些什么，但还是对细节会有一些疑问：
Listener是什么时候加载的，谁加载的是怎么执行到Listener里的方法里的我就不直接截源码的图里，因为以本人看文章的体验来说，枯燥的截图对读者帮助并不大，下面直接看根据源码画的流程图
前面说了加载监听器分为两步，其实也对应了在AbstractApplicationEventMulticaster#ListenerRetriever的两个成员变量 通过名字也能看出，下面的applicationListenerBeans是第一步通过addApplicationListenerBean加载的。而上面的applicationListeners是第二步通过addApplicationListener加载的。下面详细说一下这两种加载方式
这一步加载的是所有通过“传统手段”，正常实现ApplicationListener接口的监听器。找到这些监听器也比较好理解： String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false); 通过接口类型找到所有的beanName，就可以找到Listener1，Listener2了。
这一步是在EventListenerMethodProcessor里完成的，但这一步其实并不是完全专门为加载注解监听器的（而是主要工作是完成注解监听器的加载）。如下关键的一句话： String[] beanNames = beanFactory.getBeanNamesForType(Object.class); 它首先加载里所有的Object对象，也就是说加载里Spring里管理的所有对象，包括那些传统手段写的监听器。其中最令人兴奋的就是下面这句话：如何把注解方法变成一个监听器对象
大致原理就是通过代理或者CGLib生成动态代理对象（细节将在之后的其他文章里解释）。 其实上面关于监听器，还是跳过里一些不太重要的细节：在这两步加载前面还会加载一些Spring内部特殊的监听器。
Spring的代码千千万，硬生生的找代码肯定是困难的
以上面为例，一开始我们只知道ApplicationEventMulticaster这么个接口。现在我们想知道它是如何/何时加载监听器的，那么就需要在关键的方法上打断点，这里的关键方法就是那两个addxxx方法。首先就是找到它的实现类
接下来就是以debug方式启动Spring，发现启动过程中就停到断点处了，然后用debug的方法栈
往前点，我们可以看到上一步是在哪个位置，然后就知道这个动作的起因在哪里。 通过这种方式，就可以知道：如果想知道执行的时候的流程，那么断点应该打在我们写的监听器方法内就可以了。
Spring Event事件通知机制 源码学习 @EventListener注解使用及源码解析 观察者模式（Observer模式）详解
