【Spring】从Spring源码入手分析广播与监听并完成项目实战_spring 源码 监听器 广播

Java面试核心知识点笔记

其中囊括了JVM、锁、并发、Java反射、Spring原理、微服务、Zookeeper、数据库、数据结构等大量知识点。

Java中高级面试高频考点整理

最后分享Java进阶学习及面试必备的视频教学

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

文章目录

• • 源码解析
    • • • 发送广播
          • 监听消息
          • 案例分析
          • 消息与监听绑定
    • 实战教学
    • • • 自定义事件
          • 自定义广播
          • 自定义监听
          • 客户端

近期疫情形势严峻，情形不容乐观，周末也不敢出去浪了，躲在家里“葛优躺”。闲来无事，又翻了遍Spring的源码。不翻不知道，一翻吓一跳，之前翻过的源码已经吃进了肚子里，再见亦是陌生人。

个人建议：为了以后能快速的捡起某个知识点，最好的方法还是形成文档，下次有遗漏的时候，直接读文档，按之前的思路捋一遍，“干净又卫生”。

之前的文章中我们已经介绍过如何在项目中快速上手“事件通知机制”，相信大家已经掌握了。但是我们作为高级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方法中，大家可以去源码中查看。

实战教学

最后

整理的这些资料希望对Java开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

其实面试这一块早在第一个说的25大面试专题就全都有的。以上提及的这些全部的面试+学习的各种笔记资料，我这差不多来回搞了三个多月，收集整理真的很不容易，其中还有很多自己的一些知识总结。正是因为很麻烦，所以对以上这些学习复习资料感兴趣，

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录**

需要这份系统化的资料的朋友，可以点击这里获取