总结
虽然我个人也经常自嘲,十年之后要去成为外卖专员,但实际上依靠自身的努力,是能够减少三十五岁之后的焦虑的,毕竟好的架构师并不多。
架构师,是我们大部分技术人的职业目标,一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果,实践+机遇+努力才能助你成为优秀的架构师。
如果你也想成为一名好的架构师,那或许这份Java成长笔记你需要阅读阅读,希望能够对你的职业发展有所帮助。
之前的文章中我们已经介绍过如何在项目中快速上手“事件通知机制”,相信大家已经掌握了。但是我们作为高级javaer
,要知其然,更要知其所以然。今天就带大家从源码的角度来分析一下广播与监听的底层实现原理。
源码导入教程也给你准备好了,不来试试吗?
版本号:spring-framework-5.0.x
源码解析
为了实现广播与监听的功能,Spring
为我们提供了两个重要的函数式接口:ApplicationEventPublisher
和ApplicationListener
。前者的publishEvent()
方法为我们提供了发送广播的能力;后者的onApplicationEvent()
方法为我们提供了监听并处理事件的能力。
接下来我们就来分析一下spring
是如何运用这两种能力的。
不知道大家对单例对象的初始化调用过程是否熟悉?主要调用方法流程如下:
发送广播
applyBeanPostProcessorsBeforeInitialization
方法会去遍历该工厂创建的所有的Bean
后置处理器,然后去依次执行后置处理器对应的postProcessBeforeInitialization
方法。
在该方法的实现类中我们看到了两个熟悉的类名
不知道大家还记得不,这俩类是在beanFactory
的准备工作过程中添加的两个bean
的后置处理器,所以这个地方会依次去执行这两个类中的实现方法。
由于蓝框中类的实现方法是默认实现按照原样返回的给定的bean
,所以此处不用过多分析,我们重点来看下红框中类的方法实现。
该方法中最重要的是invokeAwareInterfaces
方法,它的作用是检测对应的bean
是否实现了某个Aware
接口,如果实现了的话就去进行相关的调用。
if (bean instanceof ApplicationEventPublisherAware) {
((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
}
我们发现在invokeAwareInterfaces
方法中出现了如上代码,这不就是和广播发送相关的吗?所以只要我们写一个类来实现ApplicationEventPublisherAware
接口,就可以在该bean
中注入一个ApplicationEventPublisher
对象,也就获得了发送广播的能力。
监听消息
applyBeanPostProcessorsAfterInitialization
方法也会去遍历该工厂创建的所有的Bean
后置处理器,然后去依次执行后置处理器对应的postProcessAfterInitialization
方法。
同样的,该方法的实现类中也有ApplicationContextAwareProcessor
和ApplicationListenerDetector
两个类,但是不同的是,前者的类的实现方法是默认实现按照原样返回的给定bean
,而后者做了相关的处理。
this.applicationContext.addApplicationListener((ApplicationListener<?>) bean);
上述代码是将实现了ApplicationListener
接口的bean
添加到监听器列表中,最终是保存在AbstractApplicationEventMulticaster
的成员变量defaultRetriever
的集合applicationListeners
中。
猜想:当发送广播消息时,就直接找到集合中的这些监听器,然后调用每个监听器的
onApplicationEvent
方法完成事件的处理。
案例分析
在refresh()
的finishRefresh()
方法中,
publishEvent(new ContextRefreshedEvent(this));
发送一条事件类型为ContextRefreshedEvent
的广播消息,用来代表Spring
容器初始化结束。通过分析发现,该方法中最主要的就是如下代码:
//真正的广播交给 applicationEventMulticaster 来完成
getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
refresh()
的initApplicationEventMulticaster()
将applicationEventMulticaster
初始化为SimpleApplicationEventMulticaster
在实现类SimpleApplicationEventMulticaster
的方法中,会找到已注册的ApplicationListener
列表,然后分别调用invokeListener
方法(将监听和事件作为参数传到方法并执行的过程就是发送广播的过程)。
底层调用的是listener.onApplicationEvent(event);
方法,也就是各个监听实现类单独处理广播消息的逻辑。
消息与监听绑定
看到这儿,你是不是已经发现了:消息类型和监听器的绑定发生在广播过程中。接下来就让我们去一探究竟
我们看一下multicastEvent()
方法中的getApplicationListeners(event, type)
方法。
在该方法中,用到了ConcurrentHashMap
类型的缓存retrieverCache
,所以每种类型的事件在广播的时候会触发一次绑定操作。它的key由事件的来源和类型确定,它的value中就包含了由事件来源和类型所确定的所有监听列表。
其中绑定的逻辑就出现在retrieveApplicationListeners
方法中,大家可以去源码中查看。
实战教学
纸上得来终觉浅,绝知此事要躬行。为了更好地理解广播与监听的流程,我们当然得用实战来加以辅佐!
自定义事件
public class MyEvent extends ApplicationContextEvent {
public MyEvent(ApplicationContext source) {
super(source);
}
}
自定义广播
@Component
public class MyPublisher implements ApplicationEventPublisherAware, ApplicationContextAware {
private ApplicationEventPublisher applicationEventPublisher;
private ApplicationContext applicationContext;
@Override
public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
this.applicationEventPublisher = applicationEventPublisher;
}
# 分享
**1、算法大厂——字节跳动面试题**
![](https://img-blog.csdnimg.cn/img_convert/f52a164ad13d3d44ac1e4d42f72a780c.webp?x-oss-process=image/format,png)
**2、2000页互联网Java面试题大全**
![](https://img-blog.csdnimg.cn/img_convert/44037d9e7611464b8f1122f876a7d64f.webp?x-oss-process=image/format,png)
**3、高阶必备,算法学习**
![](https://img-blog.csdnimg.cn/img_convert/31a3c7e7246089be7dbef696b5e48581.webp?x-oss-process=image/format,png)
> **本文已被[CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**
**[需要这份系统化的资料的朋友,可以点击这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
[CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**
**[需要这份系统化的资料的朋友,可以点击这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**