聊透Spring事件机制

语言: CN / TW / HK

 事件机制是Spring为企业级开发提供的神兵利器之一,它提供了一种低耦合、无侵入的解决方式,是我们行走江湖必备保命技能。但其实Spring事件的设计其实并不复杂,它由三部分组成:事件、发布器、监听器。事件是主体,发布器负责发布事件,监听器负责处理事件。
image.png

 在简单了解Spring事件的机制之后,本文将从源码的角度出发,和大家一起探讨:Spring事件的核心工作机制,并看一下作为企业级开发工具,Spring事件是如何支持全局异常处理和异步执行的。最后会和大家讨论目前Spring事件机制的一些缺陷和问题,话不多说,我们开始吧。

image.png

1. Spring事件如何使用

 所谓千里之行始于足下,在研究Spring的事件的机制之前,我们先来看一下Spring事件是如何使用的。通常情况下,我们使用自定义事件和内置事件,自定义事件主要是配合业务使用,自定义事件则多是做系统启动时的初始化工作或者收尾工作。

1.1 自定义事件的使用

  • 定义自定义事件
     自定义一个事件在使用上很简单,继承ApplicationEvent即可: ```java // 事件需要继承ApplicationEvent public class MyApplicationEvent extends ApplicationEvent { private Long id; public MyApplicationEvent(Long id) { super(id); this.id = id; }

    public Long getId() { return id; } } - **发布自定义事件**<br> &emsp;现在自定义事件已经有了,该如何进行发布呢?Spring提供了`ApplicationEventPublisher`进行事件的发布,我们平常使用最多的`ApplicationContext`也继承了该发布器,所以我们可以直接使用applicationContext进行事件的发布。java // 发布MyApplicationEvent类型事件 applicationContext.publishEvent(new MyApplicationEvent(1L)); - **处理自定义事件**<br> &emsp;现在事件已经发布了,谁负责处理事件呢?当然是监听器了,Spring要求监听器需要实现`ApplicationListener`接口,同时需要`通过泛型参数指定处理的事件类型`。有了监听器需要处理的事件类型信息,Spring在进行事件广播的时候,就能找到需要广播的监听器了,从而准确传递事件了。java // 需要继承ApplicationListener,并指定事件类型 public class MyEventListener implements ApplicationListener { // 处理指定类型的事件 @Override public void onApplicationEvent(MyApplicationEvent event) { System.out.println(Thread.currentThread().getName() + "接受到事件:"+event.getSource()); } } ```

1.2 Spring内置事件

1.2.1 ContextRefreshedEvent

 在ConfigurableApplicationContextrefresh()执行完成时,会发出ContextRefreshedEvent事件。refresh()是Spring最核心的方法,该方法内部完成的Spring容器的启动,是研究Spring的重中之重。在该方法内部,当Spring容器启动完成,会在finishRefresh()发出ContextRefreshedEvent事件,通知容器刷新完成。我们一起来看一下源码:

```java // ConfigurableApplicationContext.java public void refresh() throws BeansException, IllegalStateException { try { // ...省略部分非关键代码 //完成普通单例Bean的实例化(非延迟的) this.finishBeanFactoryInitialization(beanFactory);

    // 初始化声明周期处理器,并发出对应的时间通知
    this.finishRefresh();
}

}

protected void finishRefresh() { // ...省略部分非核心代码 // 发布上下文已经刷新完成的事件 this.publishEvent(new ContextRefreshedEvent(this)); } ```

 其实这是Spring提供给我们的拓展点,此时容器已经启动完成,容器中的bean也已经创建完成,对应的属性、init()、Aware回调等,也全部执行。很适合我们做一些系统启动后的准备工作,此时我们就可以监听该事件,作为系统启动后初始预热的契机。其实Spring内部也是这样使用ContextRefreshedEvent的, 比如我们常用的Spring内置的调度器,就是在接收到该事件后,才进行调度器的执行的。

java public class ScheduledAnnotationBeanPostProcessor implements ApplicationListener<ContextRefreshedEvent> { @Override public void onApplicationEvent(ContextRefreshedEvent event) { if (event.getApplicationContext() == this.applicationContext) { finishRegistration(); } } }

1.2.2 ContextStartedEvent

 在ConfigurableApplicationContextstart()执行完成时,会发出ContextStartedEvent事件。

java @Override public void start() { this.getLifecycleProcessor().start(); this.publishEvent(new ContextStartedEvent(this)); }ContextRefreshedEvent事件的触发是所有的单例bean创建完成后发布,此时实现了Lifecycle接口的bean还没有回调start(),当这些start()被调用后,才会发布ContextStartedEvent事件。

1.2.3 ContextClosedEvent

 在ConfigurableApplicationContextclose()执行完成时,会发出ContextStartedEvent事件。此时IOC容器已经关闭,但尚未销毁所有的bean。 ```java @Override public void close() { synchronized (this.startupShutdownMonitor) { this.doClose(); } }

protected void doClose() { // 发布ContextClosedEvent事件 this.publishEvent(new ContextClosedEvent(this)); } ```

1.2.4 ContextStoppedEvent

 在ConfigurableApplicationContextstop()执行完成时,会发出ContextStartedEvent事件。 java @Override public void stop() { this.getLifecycleProcessor().stop(); this.publishEvent(new ContextStoppedEvent(this)); }  该事件在ContextClosedEvent事件触发之后才会触发,此时单例bean还没有被销毁,要先把他们都停掉才可以释放资源,销毁bean。

2. Spring事件是如何运转的

 经过第一章节的探讨,我们已经清楚Spring事件是如何使用的,然而这只是皮毛而已,我们的目标是把Spring事件机制脱光扒净的展示给大家看。所以这一章节我们深入探讨一下,Spring事件的运行机制,重点我们看一下: - 事件是怎么广播给监听器的?会不会发送阻塞? - 系统中bean那么多,ApplicationListener是被如何识别为监听器的? - 监听器处理事件的时候,是同步处理还是异步处理的? - 处理的时候发生异常怎么办,后面的监听器还能执行吗?

 乍一看是不是问题还挺多,没事,不要着急,让我们一起来开启愉快的探索路程,看看Spring是怎么玩转事件的吧。

2.1 事件发布

 在第一章节,我们直接通过applicationContext发布了事件,同时也提到了,它之所以能发布事件,是因为它是ApplicationEventPublisher的子类,因此是具备事件发布能力的。但按照接口隔离原则,如果我们只需要进行事件发布,applicationContext提供的能力太多,还是推荐直接使用ApplicationEventPublisher进行操作。

2.1.1 获取事件发布器的方式

 我们先来ApplicationEventPublisher的提供的能力,它是一个接口,结构如下: ```java @FunctionalInterface public interface ApplicationEventPublisher { //发布ApplicationEvent事件 default void publishEvent(ApplicationEvent event) { publishEvent((Object) event); }

//发布PayloadApplicationEvent事件
void publishEvent(Object event);

} `` &emsp;通过源码我们发现ApplicationEventPublisher仅仅提供了事件发布的能力,支持自定义类型和PayloadApplicationEvent类型(如果没有定义事件类型,默认包装为该类型)。那我们如何获取该发布器呢,我们最常使用的@Autowired`注入是否可以呢,试一下呗。

  • 通过@Autowired 注入 ApplicationEventPublisher image-20220901164129936.png
     通过debug,我们可以直观的看到:是可以的,而且注入的就是ApplicationContext实例。也就是说注入ApplicationContext和注入ApplicationEventPublisher是等价的,都是一个ApplicationContext实例。

  • 通过ApplicationEventPublisherAware获取 ApplicationEventPublisher
     除了@Autowired注入,Spring还提供了使用ApplicationEventPublisherAware获取 ApplicationEventPublisher的方式,如果实现了这个感知接口,Spring会在合适的时机,回调setApplicationEventPublisher(),将applicationEventPublisher传递给我们。使用起来也很方便。代码所示: ```java public class UserService implements ApplicationEventPublisherAware { private ApplicationEventPublisher applicationEventPublisher;

    public void login(String username, String password){ // 1: 进行登录处理 ... // 2: 发送登录事件,用于记录操作 applicationEventPublisher.publishEvent(new UserLoginEvent(userId)); }

    // Aware接口回调注入applicationEventPublisher @Override public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) { this.applicationEventPublisher = applicationEventPublisher; } } `` &emsp;现在我们已经知道通过@AutowiredApplicationEventPublisherAware`回调都能获取到事件发布器,两种有什么区别吗? 其实区别不大,主要是调用时机的细小差别,另外就是默写特殊场景下,@Autowired注入可能无法正常注入,实际开发中完成可以忽略不计。所以优先推荐小伙伴们使用ApplicationEventPublisherAware,如果觉得麻烦,使用@Autowired也未尝不可。

image.png

如果使是自动注入模型,是无法通过setter()注入ApplicationEventPublisher的,因为在prepareBeanFactory时已经指定忽略此接口的注入了(beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class))。顺便说一句,@Autowired不算自动注入哦。

2.1.2 事件的广播方式

 现在我们已经知道,可以通过ApplicationEventPublisher发送事件了,那么这个事件发送后肯定是要分发给对应的监听器处理啊,谁处理这个分发逻辑呢?又是怎么匹配对应的监听器的呢?我们带着这两个问题来看ApplicationEventMulticaster

  • 事件是如何广播的
     要探查事件是如何广播的,需要跟随事件发布后的逻辑一起看一下:

```java @Override public void publishEvent(ApplicationEvent event) { this.publishEvent(event, null); }

protected void publishEvent(Object event, @Nullable ResolvableType eventType) { // ...省略部分代码 if (this.earlyApplicationEvents != null) { this.earlyApplicationEvents.add(applicationEvent); } else { // 将事件广播给Listener this.getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType); } }

// 获取事件广播器 ApplicationEventMulticaster getApplicationEventMulticaster() throws IllegalStateException { if (this.applicationEventMulticaster == null) { throw new IllegalStateException("ApplicationEventMulticaster not initialized - " + "call 'refresh' before multicasting events via the context: " + this); } return this.applicationEventMulticaster; } ```  通过上面源码,我们发现发布器直接把事件转交给applicationEventMulticaster了,我们再去里面看一下广播器里面做了什么。

```java // SimpleApplicationEventMulticaster.java public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) { // ...省略部分代码 // getApplicationListeners 获取符合的监听器 for (ApplicationListener<?> listener : getApplicationListeners(event, type)) { // 执行每个监听器的逻辑 invokeListener(listener, event); } }

private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) { try { // 调用监听器的onApplicationEvent方法进行处理 listener.onApplicationEvent(event); } } ```  看到这里,我们发现事件的分发逻辑:先找到匹配的监听器,然后逐个调用onApplicationEvent()进行事件处理。

image.png

  • 事件和监听器是如何匹配的
     通过上述源码,我们发现通过getApplicationListeners(event, type)找到了所有匹配的监听器,我们继续跟踪看一下是如何匹配的。

```java

protected Collection<ApplicationListener<?>> getApplicationListeners( ApplicationEvent event, ResolvableType eventType) { // 省略缓存相关代码 return retrieveApplicationListeners(eventType, sourceType, newRetriever); }

private Collection<ApplicationListener<?>> retrieveApplicationListeners( ResolvableType eventType, @Nullable Class<?> sourceType, @Nullable CachedListenerRetriever retriever) { // 1: 获取所有的ApplicationListener Set<ApplicationListener<?>> listeners; Set listenerBeans; synchronized (this.defaultRetriever) { listeners = new LinkedHashSet<>(this.defaultRetriever.applicationListeners); listenerBeans = new LinkedHashSet<>(this.defaultRetriever.applicationListenerBeans); }

for (ApplicationListener<?> listener : listeners) {
    // 2: 遍历判断是否匹配
    if (supportsEvent(listener, eventType, sourceType)) {
        if (retriever != null) {
            filteredListeners.add(listener);
        }
        allListeners.add(listener);
    }
}

}

protected boolean supportsEvent( ApplicationListener<?> listener, ResolvableType eventType, @Nullable Class<?> sourceType) { GenericApplicationListener smartListener = (listener instanceof GenericApplicationListener ? (GenericApplicationListener) listener : new GenericApplicationListenerAdapter(listener)); // supportsEventType 根据ApplicationListener的泛型, 和事件类型,看是否匹配 // supportsSourceType 根据事件源类型,判断是否匹配 return (smartListener.supportsEventType(eventType) && smartListener.supportsSourceType(sourceType)); } ```  通过源码跟踪,我们发现监听器匹配是根据事件类型匹配的,先获取容器中所有的监听器,在用supportsEvent()去判断对应的监听器是否匹配事件。这里匹配主要看两点: 1. 判断事件类型和监听器上的泛型类型,是否匹配(子类也能匹配)。 2. 监听器是否支持事件源类型,默认情况下,都是支持的。
如果两者都匹配,就转发给处理器处理。

image.png

  • ApplicationEventMulticaster是如何获取的(选读)
     在事件广播时,Spring直接调用getApplicationEventMulticaster()去获取属性applicationEventMulticaster,并且当applicationEventMulticaster为空时,直接异常终止了。那么就要求该成员变量提早初始化,那么它是何时初始化的呢。

```java public void refresh() throws BeansException, IllegalStateException { // ...省略无关代码 // 初始化事件广播器(转发ApplicationEvent给对应的ApplicationListener处理) this.initApplicationEventMulticaster(); }

protected void initApplicationEventMulticaster() { ConfigurableListableBeanFactory beanFactory = this.getBeanFactory(); // spring容器中存在,直接返回 if (beanFactory.containsLocalBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME)) { this.applicationEventMulticaster = beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class); if (this.logger.isTraceEnabled()) { this.logger.trace("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]"); } } else { // 容器中不存在,创建SimpleApplicationEventMulticaster,放入容器 this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory); beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster); if (this.logger.isTraceEnabled()) { this.logger.trace("No '" + APPLICATION_EVENT_MULTICASTER_BEAN_NAME + "' bean, using " + "[" + this.applicationEventMulticaster.getClass().getSimpleName() + "]"); } } } `` &emsp;看到这里,是不是豁然开朗,原来在容器启动的时候,专门调用了initApplicationEventMulticaster()applicationEventMulticaster`进行了初始化,并放到了spring容器中。

其实这里还有个问题,就是事件整体的初始化流程在BeanFactoryPostProcessor之后,如果在自定义的BeanFactoryPostProcessor发布事件,此时applicationEventMulticaster还没有初始化,监听器也没有注册,是无法进行事件的广播的。该问题在Spring3之前普遍存在,在最近的版本已经解决,其思路是:先将早期事件放入集合中,待广播器、监听器注册后,再从集合中取出进行广播。

2.2 事件监听器

 监听器是负责处理事件的,在广播器将对应的事件广播给它之后,它正式上岗开始处理事件。Spring默认的监听器是同步执行的,并且支持一个事件由多个监听器处理,并可通过@Order指定监听器处理顺序。

2.2.1 定义监听器的方式

image.png - 实现ApplicationListener定义监听器
 第一种方式定义的方式当然是通过直接继承ApplicationListener,同时不要忘记通过泛型指定事件类型,它可是将事件广播给监听器的核心匹配标志。 java public class MyEventListener implements ApplicationListener<MyApplicationEvent> { @Override public void onApplicationEvent(MyApplicationEvent event) { System.out.println(Thread.currentThread().getName() + "接受到事件:"+event.getSource()); } }

通过ApplicationListener定义的监听器,本质上是一个单事件监听器,也就是只能处理一种类型的事件。

  • 使用@EventListener定义监听器
     第二种方式我们还可以使用@EventListener标注方法为监听器,该注解标注的方法上,方法参数为事件类型,标注该监听器要处理的事件类型。 ```java public class AnnotationEventListener { // 使用@EventListener标注方法为监听器,参数类型为事件类型 @EventListener public void onApplicationEvent(MyApplicationEvent event) { System.out.println(Thread.currentThread().getName() + "接受到事件:"+event.getSource()); }
@EventListener
public void onApplicationEvent(PayloadApplicationEvent payloadApplicationEvent) {
    System.out.println(Thread.currentThread().getName() + "接受到事件:"+payloadApplicationEvent.getPayload());
}

} ```

通过广播器分发事件的逻辑,我们知道事件只能分发给ApplicationListener类型的监听器实例处理,这里仅仅是标注了@EventListener的方法,也能被是识别成ApplicationListener类型的监听器吗?答案是肯定的,只是Spring在底层进行了包装,偷偷把@EventListener标注的方法包装成了ApplicationListenerMethodAdapter,它也是ApplicationListener的子类,这样就成功的把方法转换成ApplicationListener实例了,后续章节我们会详细揭露Spring偷梁换柱的小把戏,小伙伴们稍安勿躁。

2.2.2 ApplicationListener监听器是如何被识别的

 本小节我们一起看一下监听器是如何被是识别的,毕竟大多数情况下,我们只是直接加了@Component注解,然后实现了一下ApplicationListener接口,并没有特殊指定为监听器。那有没有可能就是基于这个继承关系,Spring自己在容器中进行类型查找呢? ```java public void refresh() throws BeansException, IllegalStateException { try { // ...省略部分代码 // 初始化各种监听器 this.registerListeners(); } }

// 注册监听器 protected void registerListeners() { // 1: 处理context.addApplicationListener(new MyEventListener()) 方式注册的监听器,并将监听器注册到广播器中, for (ApplicationListener<?> listener : this.getApplicationListeners()) { this.getApplicationEventMulticaster().addApplicationListener(listener); }

// 2: 去Spring容器中获取监听器(处理扫描的或者register方式注册的),同样也是添加到广播器中 String[] listenerBeanNames = this.getBeanNamesForType(ApplicationListener.class, true, false); for (String listenerBeanName : listenerBeanNames) { this.getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName); } } `` &emsp;通过上述源码跟踪,我们发现原来在容器refresh()的时候,专门有个步骤是用来初始化各种监听器的。它的具体实现是:先把通过addApplicationListener()直接指定的注册为监听器 -> 再通过类型查找,把当做普通bean注册到容器中,类似是ApplicationListener`的找了出来 -> 缓存到ApplicationEventMulticaster中的监听器集合中了。一路跟踪下来,确实是根据类型查找的,和我们的猜想完全一致。

2.2.3 @EventListener标注的处理器是如何识别注册的

 本小节我们探究一下,标注了@EventListener的方法是如何被包装成ApplicationListener实例的。我们直接从源码入手,Spring在实例化bean后,调用了afterSingletonsInstantiated()@EventListener的方法进行了保证,我们一起看一下。

```java public void refresh() throws BeansException, IllegalStateException { try { // ...省略部分代码 //完成普通单例Bean的实例化(非延迟的) this.finishBeanFactoryInitialization(beanFactory); // ...省略部分代码 } }

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) { // ...省略部分代码 // 初始化非延迟加载的单例bean beanFactory.preInstantiateSingletons(); }

@Override public void preInstantiateSingletons() throws BeansException { List beanNames = new ArrayList<>(this.beanDefinitionNames); // 1: 完成bean的实例化 for (String beanName : beanNames) { //通过beanName获取bean,bean不存在会创建bean getBean(beanName); }

// 2: 调用bean的后置处理方法
for (String beanName : beanNames) {
    // ...省略部分代码
    // 调用到EventListenerMethodProcessor的afterSingletonsInstantiated(),完成@EventListener的方法的转换注册
    smartSingleton.afterSingletonsInstantiated();
}

}

// EventListenerMethodProcessor.java public void afterSingletonsInstantiated() { // ...省略部分代码 for (String beanName : beanNames) { // ...省略部分代码 processBean(beanName, type); } }

private void processBean(final String beanName, final Class<?> targetType) { // 1: 解析bean上加了@EventListener的方法 Map annotatedMethods = null; try { annotatedMethods = MethodIntrospector.selectMethods(targetType, (MethodIntrospector.MetadataLookup) method -> AnnotatedElementUtils.findMergedAnnotation(method, EventListener.class)); }

// ...省略部分代码
// 2: 遍历加了@EventListener的方法,注册为事件监听器
for (Method method : annotatedMethods.keySet()) {
    for (EventListenerFactory factory : factories) {
        if (factory.supportsMethod(method)) {
            Method methodToUse = AopUtils.selectInvocableMethod(method, context.getType(beanName));
            // 2.1 通过EventListenerFactory,将方法创建为监听器实例(ApplicationListenerMethodAdapter)
            ApplicationListener<?> applicationListener = factory.createApplicationListener(beanName, targetType, methodToUse);
            if (applicationListener instanceof ApplicationListenerMethodAdapter) {
                    ((ApplicationListenerMethodAdapter) applicationListener).init(context, this.evaluator);
            }
            // 2.2 注册为ApplicationListener
            context.addApplicationListener(applicationListener);
            break;
        }
    }
}
// ...省略部分代码

} `` &emsp;我们整理一下调用关系:refresh()->finishBeanFactoryInitialization(beanFactory) ->beanFactory.preInstantiateSingletons() ->eventListenerMethodProcessor.afterSingletonsInstantiated()->eventListenerMethodProcessor.processBean()`;在容器中所有的bean实例化后,会再次遍历遍历所有bean,调用SmartInitializingSingleton类型的bean的afterSingletonsInstantiated()的方法,此时符合条件的EventListenerMethodProcessor就会被调用,进而通过processBean(),先找出标注了@EventListener的方法,然后遍历这些方法,通过EventListenerFactory工厂,包装方法为EventListener实例,最后在注册到容器中。至此,完成了查找,转换的过程。
image.png

关于@EventListener标注方法的解析时机,笔者首先想到的应该和@Bean的处理时机一致,在扫描类的时候,就解析出来加了@EventListener的方法,抽象为BeanDefinition放到容器中,后面实例化时候,和正常扫描出来的bean是一样的实例化流程。但是查找下来发现Spring并没有这样处理,而是在bean初始化后回调阶段处理的。究其原因,大概是@Bean真的是需要托付给Spring管理,而@EventListener只是一个标识,无需放入放入容器,防止对完暴露所致吧。

  • EventListenerMethodProcessors是如何注册的
     通过上述的源码分析,我们清楚对于@EventListener的方法的处理,EventListenerMethodProcessor可谓是至关重要,那么他是怎么注册到Spring中的。而且我们也没有通过@EnableXXX进行开启啊。其实Spring除了管理我们定义的bean,还会有一些内置的bean,来承接一些Spring核心工作,这些内置的bean一般在application容器创建的时候,就放入到Spring容器中了。下面我们来看一下是不是这样: ```java // 构造方法 public AnnotationConfigApplicationContext() { // 1: 初始化BeanDefinition渲染器,注册一下Spring内置的BeanDefinition this.reader = new AnnotatedBeanDefinitionReader(this); this.scanner = new ClassPathBeanDefinitionScanner(this); }

// AnnotatedBeanDefinitionReader.java public class AnnotatedBeanDefinitionReader { public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) { // ...省略部分代码 // 注册一些内置后置处理器的BeanDefinition,是spring这两个最核心的功能类 AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); } }

// AnnotationConfigUtils.java public static Set registerAnnotationConfigProcessors( BeanDefinitionRegistry registry, @Nullable Object source) { // ...省略部分代码 // 注册EventListenerMethodProcessor if (!registry.containsBeanDefinition(EVENT_LISTENER_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(EventListenerMethodProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_PROCESSOR_BEAN_NAME)); } } ```

2.3 异步处理事件

 通过上面的分析,我们知道事件在广播时是同步执行的,广播流程为:先找到匹配的监听器 -> 逐个调用onApplicationEvent()进行事件处理,整个过程是同步处理的。下面我们做一个测试验证一下: ```java public void applicationListenerTest(){ AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(); context.register(AnnotationEventListener.class); context.refresh(); System.out.printf("线程:[%s],时间:[%s],开始发布事件\n", new Date(), Thread.currentThread().getName()); context.publishEvent(new MyApplicationEvent(1L)); System.out.printf("线程:[%s],时间:[%s],发布事件完成\n", new Date(), Thread.currentThread().getName()); context.stop(); }

public class AnnotationEventListener { @EventListener @Order(1) public void onApplicationEvent(MyApplicationEvent event) { Date start = new Date(); Thread.sleep(3000); System.out.printf("线程:[%s],监听器1,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource()); }

@EventListener
@Order(2)
public void onApplicationEvent2(MyApplicationEvent event) {
    Date start = new Date();
    System.out.printf("线程:[%s],监听器2,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

}

// 输出信息: // 线程:[main],时间[22:59:24],开始发布事件 // 线程:[main],监听器1,接收时间:[22:59:24],处理完成时间:[22:59:27],接收到事件:1 // 线程:[main],监听器1,接收时间:[22:59:27],处理完成时间:[22:59:27],接收到事件:1 // 线程:[main],时间[22:59:27],,发布事件完成 ```  通过上述示例代码,发现确实是同步调用的,处理线程都是main,监听器1处理缓慢,监听器2只能默默等待监听器1处理后才能接收到事件。这能满足我们的需求吗,毕竟现在系统动辄就要求毫秒计返回,QPS没有1000+你都不好意思出门,哪怕只有十个用户😂。

 除了性能问题,我们基于真实业务场景出发,考虑一下什么场景下,我们使用事件比较合适。个人使用最多的场景是:在执行某个业务时,需要通知别的业务方,该业务的执行情况时,会使用事件机制进行通知。就拿这个场景来说,我们考虑几个问题: 1. 我们是否关心监听者的执行时机? 2. 我们是否关心监听者的执行结果?

 大多数情况下,其实我们并不关心的监听者什么时候执行,执行结果如何的。如果对执行结果有依赖,通常直接调用了,如果有可能,还能享受事务的便利,还借助事件干什么呢。所以这里其实有个需求,希望Spring事件的处理是异步的,那如何实现呢?

2.3.1 通过注入taskExecutor,异步处理事件

 通过前文的分析,我们知道事件的广播是由ApplicationEventMulticaster进行处理的,那我们去看看,是否支持异步处理呢。 ```java @Override public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) { // 获取执行线程池 Executor executor = getTaskExecutor(); for (ApplicationListener<?> listener : getApplicationListeners(event, type)) { // 如果存在线程池,使用线程池异步执行 if (executor != null) { executor.execute(() -> invokeListener(listener, event)); } // 如果不存在线程池,同步执行 else { invokeListener(listener, event); } } }

// 获取线程池 protected Executor getTaskExecutor() { return this.taskExecutor; }

// 设置线程池 public void setTaskExecutor(@Nullable Executor taskExecutor) { this.taskExecutor = taskExecutor; } ```

 通过源码我们发现,其实Spring提供了使用线程池异步执行的逻辑,前提是需要先设置线程池,只是这里设置线程池的方式稍微麻烦些,需要通过applicationEventMulticaster实例的setTaskExecutor()设置,下面我们试一下是否可行。

```java public void applicationListenerTest(){ AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(); context.register(AnnotationEventListener.class); context.refresh(); ApplicationEventMulticaster multicaster = context.getBean(AbstractApplicationContext.APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class); if (multicaster instanceof SimpleApplicationEventMulticaster) { ((SimpleApplicationEventMulticaster) multicaster).setTaskExecutor(Executors.newFixedThreadPool(10)); } System.out.printf("线程:[%s],时间:[%s],开始发布事件\n", new Date(), Thread.currentThread().getName()); context.publishEvent(new MyApplicationEvent(1L)); System.out.printf("线程:[%s],时间:[%s],发布事件完成\n", new Date(), Thread.currentThread().getName()); context.stop(); }

public class AnnotationEventListener { @EventListener @Order(1) public void onApplicationEvent(MyApplicationEvent event) { Date start = new Date(); Thread.sleep(3000); System.out.printf("线程:[%s],监听器1,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource()); }

@EventListener
@Order(2)
public void onApplicationEvent2(MyApplicationEvent event) {
    Date start = new Date();
    System.out.printf("线程:[%s],监听器2,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

}

// 输出信息: // 线程:[main],时间[22:57:13],开始发布事件 // 线程:[main],时间[22:57:13],,发布事件完成 // 线程:[pool-2-thread-1],监听器2,接收时间:[22:57:13],处理完成时间:[22:57:13],接收到事件:1 // 线程:[pool-2-thread-2],监听器1,接收时间:[22:57:13],处理完成时间:[22:57:16],接收到事件:1 ```  经过测试发现:设置了线程池之后,监听器确实是异步执行的,并且是全局生效,对所有类型的监听器都适用。只是这里的设置稍显不便,需要先获取到applicationEventMulticaster这个bean之后,再使用内置方法设置。

2.3.2 使用@Async,异步处理事件

 通过注入线程池,是全局生效的。如果我们项目中有些事件需要异步处理,又有些事件需要同步执行的,怎么办,总不能告诉你的leader做不了吧。NO,那不是显得我很没有用。面对这种情况,我们可以借助@Async注解,使单个监听器异步执行。我们测试一下:

```java // 使用@EnableAsync开启异步 @EnableAsync public class AnnotationEventListener {

@EventListener
@Order(1)
public void onApplicationEvent(MyApplicationEvent event) {
    Date start = new Date();
    Thread.sleep(3000);
    System.out.printf("线程:[%s],监听器1,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

@EventListener
@Order(2)
public void onApplicationEvent2(MyApplicationEvent event) {
    Date start = new Date();
    Thread.sleep(1000);
    System.out.printf("线程:[%s],监听器2,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

}

// 输出信息: // 线程:[main],时间[23:18:32],开始发布事件 // 线程:[main],监听器1,接收时间:[23:18:32],处理完成时间:[23:18:35],接收到事件:1 // 线程:[main],时间[23:18:35],,发布事件完成 // 线程:[SimpleAsyncTaskExecutor-1],监听器2,接收时间:[23:18:35],处理完成时间:[23:18:36],接收到事件:1 ```  经过测试发现:在@Async的加持下,确实可以控制某个监听器异步执行。其实@Async也是使用了线程池执行的,对@Async感兴趣的同学可以自行查阅资料,这里我们不做展开了。

image.png

2.4 全局异常处理

 通过我们长时间的啰嗦,聪明的你肯定清楚:Spring事件的处理,默认是同步依次执行。那如果前面的监听器出现了异常,并且没有处理异常,会对后续的监听器还能顺利接收该事件吗?其实不能的,因为异常中断了事件的发送了,这里我们不做演示了,有兴趣的同学们可以自行验证一下。

那如果我们设置了异步执行呢,还会有影响吗,对线程池有所了解的同学肯定可以给出答案:不会,因为不是一个线程执行,是不会互相影响的。

 难道同步执行我们就要在每个监听器都try catch一下,避免相互影响吗,不能全局处理吗?当前可以了,贴心的Spring为了简化我们的开发逻辑,特意提供了ErrorHandler来统一处理,话不多说,我们赶紧来试一下吧。

```java public class AnnotationEventListener {

@EventListener
@Order(1)
public void onApplicationEvent(MyApplicationEvent event) {
    Date start = new Date();
    // 制造异常
    int i = 1/0;
    System.out.printf("线程:[%s],监听器1,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

@EventListener
@Order(2)
public void onApplicationEvent2(MyApplicationEvent event) {
    Date start = new Date();
    System.out.printf("线程:[%s],监听器2,接收时间:[%s],处理完成时间:[%s],接收到事件:%s\n", Thread.currentThread().getName(), start, new Date(), event.getSource());
}

}

// 测试方法 public void applicationListenerTest() throws InterruptedException { AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(); context.register(AnnotationEventListener.class); context.refresh(); ApplicationEventMulticaster multicaster = context.getBean(AbstractApplicationContext.APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class); if (multicaster instanceof SimpleApplicationEventMulticaster) { // 简单打印异常信息 ((SimpleApplicationEventMulticaster) multicaster).setErrorHandler(t -> System.out.println(t)); } System.out.printf("线程:[%s],时间:[%s],开始发布事件\n", new Date(), Thread.currentThread().getName()); context.publishEvent(new MyApplicationEvent(1L)); System.out.printf("线程:[%s],时间:[%s],发布事件完成\n", new Date(), Thread.currentThread().getName()); context.stop(); }

// 输出信息: // 线程:[main],时间[23:35:15],开始发布事件 // java.lang.ArithmeticException: / by zero // 线程:[main],监听器2,接收时间:[23:35:15],处理完成时间:[23:35:15],接收到事件:1 // 线程:[main],时间[23:35:15],,发布事件完成 ```  经过测试发现:设置了ErrorHandler之后,确实可以对异常进行统一的管理了,再也不用繁琐的try catch了,今天又多了快乐划水五分钟的理由呢。老规矩,我们不光要做到知其然,还要做到知其所以然,我们探究一下为什么加了ErrorHandler之后,就可以全局处理呢?

java protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) { // 获取ErrorHandler ErrorHandler errorHandler = getErrorHandler(); // 如果ErrorHandler存在,监听器执行出现异常,交给errorHandler处理,不会传递向上抛出异常。 if (errorHandler != null) { try { doInvokeListener(listener, event); } catch (Throwable err) { errorHandler.handleError(err); } } else { // 调用监听器处理 doInvokeListener(listener, event); } }  经过阅读源码,我们发现:Sring先查找是否配置了ErrorHandler,如果配置了,在发生异常的时候,把异常信息转交给errorHandler处理,并且不会在向上传递异常了。这样可以达到异常全局处理的效果了。

3. Spring事件机制存在什么问题

3.1 发布阻塞

 Spring发布事件的时候,由applicationEventMulticaster来处理分发逻辑,这是单线程处理,处理逻辑我们分析过,就是:找到事件对应的监听器(有缓存) -> 逐个分发给监听器处理(默认同步,可异步)。我们考虑一下这种设计会不会有性能问题了?同步执行的情况我们就不讨论了,对应的场景一定是事件发生频率较低,这种场景讨论性能没有意义。

 我们主要讨论异步模式,无论是@Async还是注入线程池,本质都是:通过线程池执行,并且线程池的线程是所有监听器共同使用的(@Async对应的线程池供所有加了@Async的方法使用)。我们都清楚线程池的执行流程:先创建线程执行任务,之后会放到缓冲队列,最后可能直接拒绝。

 基于共享线程池执行的监听器的模式,有什么问题呢?最严重的问题就是:监听器的执行速度会互相影响、甚至会发生阻塞。假如某一个监听器执行的很慢,把线程池中线程都占用了,此时其他的事件虽然发布但没有资源执行,只能在缓存队列等待线程释放,哪怕该事件的处理很快、很重要,也不行。

 其实这里可以参考Netty的boss-work工作模型,广播器只负责分发事件,调度执行监听器的逻辑交给由具体的work线程负责会更合适。

3.2 无法订制监听器执行线程数

 正是由于每种事件产生的数量、处理逻辑、处理速度差异化可能很大,所以每个监听器都有适合自己场景的线程数,所以为每个监听器配置线程池就显得尤为重要。Spring事件机制,无法单独为事件(或者监听器)设置线程池,只能共用线程池,无法做到精准控制,线程拥堵或者线程浪费出现的几率极大。当然,我们也可以在监听器内部,接收到事件后使用自定义的线程池处理,但是我们更希望简单化配置就能支持

 关于Spring事件机制存在的问题,笔者在项目中借助内存队列Disruptor存储事件,采用双总线的思想实现自研项目event-bus,解决了Spring事件机制不完美的部分。后续有机会再和大家分享该项目的详细情况。