事件 简单来说就是发生了什么，然后争对这个发生的操作 怎么处理。比如 页面上有个 按钮，当点击的时候，应该怎么处理。看下下面的代码
$('#btn').on('click',function(){
console.log('btn click event')
})
通过 js 我们知道,当点击按钮时,会打印 btn click event 这么一句话。
但不点击时,什么也不会发生。
从上可以分析得到
- 有
按钮这么个东东, 发生的动作会作用在它身上， 我们称 这个 按钮为事件源 - 有
点击(click)这么个动作,作用在 事件源 上, 可以将这一过程 抽象为事件对象。发生的事件中要包含事件源，这样可以在对事件处理的操作中获取到事件源 - 有
console.log()这么个操作,这表示发生了这个事件 应该怎么处理的操作，我们将这一过程抽象为事件监听
即某个 事件监听器（一个函数或者方法） 会一直监视着某个 事件源（比如按钮） 的某个 操作(比如点击)
当发生相应的动作后，这个监听器就会执行相应的操作。
需要注意的是：
- 事件对象中 包含事件源 ，也就说 事件源是事件对象的一个属性
- 监听器 需要注册到 事件源上
Java 中的事件
在 Java 中
- 事件对象 被抽象到
java.util.EventObject, 这个对象中包含一个 Object 的属性，也即 事件源 (可扩展) - 事件监听器 被抽象到
java.util.EventListener中 ，这是一个标识接口，需要自己定义监听方法 - 事件源 需要自己定义
在 Java 中 模拟 按钮点击事件 如下
事件对象：
public class ClickEventObject extends EventObject {
/**
* 这个msg 可随意扩展
*/
private String msg;
public ClickEventObject(Object source, String msg) {
super(source);
this.msg = msg;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
}
事件监听器
public interface ClickEventListener extends EventListener {
/**
* 事件处理 (我这里是接口)
* @param eventObject 事件对象
*/
void handleEvent(EventObject eventObject);
}
事件源
public class Button {
private ClickEventListener clickEventListener;
/**
* 注册 监听器
* 我这里只是用了单个 EventListener ,你可以改成 List<EventListener> 这样一个事件源就可以注册多个监听器了
* @param clickEventListener 点击事件监听器
*/
public void registerListener(ClickEventListener clickEventListener) {
this.clickEventListener = clickEventListener;
}
/**
* 触发事件
*/
public void triggerClick() {
// this 表示事件源本身 这样也就是button
ClickEventObject clickEventObject = new ClickEventObject(this,"点击事件处理");
this.clickEventListener.handleEvent(clickEventObject);
}
}
测试
public static void main(String[] args) {
// 事件源
Button button = new Button();
// 注册监听器
button.registerListener(new ClickEventListener() {
// 实例化 监听器处理
@Override
public void handleEvent(EventObject eventObject) {
if (eventObject instanceof ClickEventObject) {
System.out.println(((ClickEventObject) eventObject).getMsg());
}
}
});
// 出发点击事件
button.triggerClick();
}
可以看到
- 事件对象只是关联事件源和事件监听器的中间对象，它其中包含 事件源
- 事件监听器需要注册到事件源上
Spring 中的事件
在 spring 的事件中 其实也是扩展了 java 中的 EventListener 和 EventObject
ApplicationEvent 直接继承了 EventObject
ApplicationListener 直接继承了 EventListener ,并且定义了 onApplicationEvent 方法，需要注意这里使用了泛型指定了特定的 EventObject
在 spring 中写一个 按钮 hover 的事件如下
事件对象
public class HoverEvent extends ApplicationEvent {
/**
* 自定义的消息 ，这个可以随意扩展
*/
private String message;
public HoverEvent(Object source, String message) {
super(source);
this.message = message;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
事件监听器
@Component
public class HoverListener implements ApplicationListener<HoverEvent> {
/**
* 事件处理
* @param hoverEvent hover事件
*/
@Override
public void onApplicationEvent(HoverEvent hoverEvent) {
System.out.println(hoverEvent.getMessage());
}
}
事件源
@Component
public class Button {
@Autowired
ApplicationContext applicationContext;
public void triggerHover(String message) {
applicationContext.publishEvent(new HoverEvent(this,message));
}
}
测试
public static void main(String[] args) {
AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(Config.class);
Button button = applicationContext.getBean(Button.class);
button.triggerHover("Hover事件处理");
}
其中 Config.class 是 spring 启动时的 配置类,这里直接将 事件源 和 事件监听器 交给 spring 管理
@ComponentScan("com.slarn.event.spring")
@Configuration
public class Config {
}
从上面代码可以看到在 事件源 中，注入了 ApplicationContext，触发 triggerHover 后 ，将操作交给了 applicationContext.publishEvent(EventObject) 方法
从这里可以猜测，applicationContext 是触发事件者，在 publishEvent 中必然有 调用 最终的事件处理方法,即最终会调用 HoverListener 的 onApplicationEvent(EventObject) 方法
跟踪代码可以发现 其调用栈如下：
org.springframework.context.ApplicationEventPublisher#publishEvent(org.springframework.context.ApplicationEvent)
--> org.springframework.context.support.AbstractApplicationContext#publishEvent(java.lang.Object, org.springframework.core.ResolvableType)
--> org.springframework.context.support.AbstractApplicationContext#getApplicationEventMulticaster
--> org.springframework.context.event.ApplicationEventMulticaster#multicastEvent(org.springframework.context.ApplicationEvent, org.springframework.core.ResolvableType)
--> org.springframework.context.event.SimpleApplicationEventMulticaster#invokeListener
-- > org.springframework.context.event.SimpleApplicationEventMulticaster#doInvokeListener
在 SimpleApplicationEventMulticaster#doInvokeListener 的方法中 可以看到 最终执行了 listener.onApplicationEvent(event); 方法，完成事件的回调。
到这里你可能会发现一个问题就是,之前说 事件监听器 是要注册到事件源上，但是在上面的 Button 中,却没有这个操作，这是怎么回事呢？是在哪里注册的呢？
带着这个问题，我们重新看下上面的调用栈 ，最终是执行了 listener.onApplicationEvent(event) ，那么这个 listener 是怎么来的呢?
往上找发现有如下代码
org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent()
@Override
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
Executor executor = getTaskExecutor();
for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
if (executor != null) {
executor.execute(() -> invokeListener(listener, event));
}
else {
invokeListener(listener, event);
}
}
}
由此可以看到 getApplicationListeners(event, type ) 可以获取到所有的监听器，也可以看出来 一个事件源上 可能有多个监听器。
这里就是 获取所有的监听器，然后遍历执行每个 listener 的 onApplicationEvent 方法
继续跟踪 getApplicationListeners()，发现他是 org.springframework.context.event.AbstractApplicationEventMulticaster#getApplicationListeners() 在这个地方调用的 然后会发现 AbstractApplicationEventMulticaster 其实是 ApplicationEventMulticaster 的实现类,打开这个 ApplicationEventMulticaster 瞄一眼，发现了什么
public interface ApplicationEventMulticaster {
/**
* Add a listener to be notified of all events.
* @param listener the listener to add
*/
void addApplicationListener(ApplicationListener<?> listener);
/**
* Add a listener bean to be notified of all events.
* @param listenerBeanName the name of the listener bean to add
*/
void addApplicationListenerBean(String listenerBeanName);
/**
* Remove a listener from the notification list.
* @param listener the listener to remove
*/
void removeApplicationListener(ApplicationListener<?> listener);
/**
* Remove a listener bean from the notification list.
* @param listenerBeanName the name of the listener bean to remove
*/
void removeApplicationListenerBean(String listenerBeanName);
/**
* Remove all listeners registered with this multicaster.
* <p>After a remove call, the multicaster will perform no action
* on event notification until new listeners are registered.
*/
void removeAllListeners();
/**
* Multicast the given application event to appropriate listeners.
* <p>Consider using {@link #multicastEvent(ApplicationEvent, ResolvableType)}
* if possible as it provides better support for generics-based events.
* @param event the event to multicast
*/
void multicastEvent(ApplicationEvent event);
/**
* Multicast the given application event to appropriate listeners.
* <p>If the {@code eventType} is {@code null}, a default type is built
* based on the {@code event} instance.
* @param event the event to multicast
* @param eventType the type of event (can be {@code null})
* @since 4.2
*/
void multicastEvent(ApplicationEvent event, @Nullable ResolvableType eventType);
}
其中定义了一个 void addApplicationListener(ApplicationListener<?> listener); 方法，看到这里你会想到什么？ 通过名字我们可以猜测 这里有可能就是 注册监听器 的地方，为了验证，我们直接在这方法的实现类上 打上一个断点
这个方法的实现类为
org.springframework.context.event.AbstractApplicationEventMulticaster#addApplicationListener
如果你对 spring bean 生命周期有一定了解的话，通过调试 跟踪调用栈 可以发现：
在 spring 初始化 bean [实例化，填充属性之后] 的时候（也就是执行 AbstractAutowireCapableBeanFactory#initializeBean(）方法）
会在初始化方法调用之后 调用 applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
在这个方法中 获取所有的后置处理器（BeanPostProcessor），然后执行每个后置处理器的 postProcessAfterInitialization() 方法
其中有一个后置处理器为 ApplicationListenerDetector，在他的 postProcessAfterInitialization() 方法中 有如下代码
最终在这个操作里面 把 类型为 ApplicationListener 的 listener 加入到 org.springframework.context.event.AbstractApplicationEventMulticaster.ListenerRetriever#applicationListeners 这个 Set 集合中。
这样在发布（publishEvent）的时候 从这里获取 所有的 listener 然后遍历调用 listener 的 onApplicationEvent 就和上面对应起来了
你可能会问 这个 ApplicationListenerDetector 这个后置处理器 上面为什么能够获取到，其实 这是 spring 内部 手动注册的，注册的代码在 ApplicationContext 刷新 refresh()方式时
org.springframework.context.support.AbstractApplicationContext#registerBeanPostProcessors
--> org.springframework.context.support.PostProcessorRegistrationDelegate#registerBeanPostProcessors(org.springframework.beans.factory.config.ConfigurableListableBeanFactory, org.springframework.context.support.AbstractApplicationContext)
在这个最后一段代码为：
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
另外细心一下你会发现:
- applicationContext 的 publishEvent 方法 其实是 ApplicationEventPublisher 这个接口指定的方法，表示发布事件 （事件触发者），在 AbstractApplicationContext 中对这方法 进行了实现
- ApplicationEvent 实现 有 ApplicationContextEvent,ContextRefreshedEvent 这个里面你会发现 source 其实换成了 ApplicationContext，也就是说 ApplicationContext 就是事件源
总结一下：
- spring 在实例化 bean 之前 会手动注册一个后置处理器
ApplicationListenerDetector - 在实例化 bean ，填充属性 之后的 初始化 bean 中 initializeBean 方法的
postProcessAfterInitialization方法中会获取 所有的后置处理器 遍历执行处理，其中就包括上面的 ApplicationListenerDetector - 在
ApplicationListenerDetector中 会判断 bean 是否是 ApplicationListener，如果是的话就 把这个 bean(listener) 加入到org.springframework.context.event.AbstractApplicationEventMulticaster.ListenerRetriever#applicationListeners这个 Set 集合中 - AbstractApplicationEventMulticaster 这个类 是 AbstractApplicationContext 抽象类中的一个 属性（并且不为空，在 refresh()方法的
initApplicationEventMulticaster()中初始化了一个SimpleApplicationEventMulticaster的多播器），也就是说 ApplicationContext 有AbstractApplicationEventMulticaster，即也能能获取到所有的 listeners - ApplicationContext 继承了 ApplicationEventPublisher，同时 AbstractApplicationContext 也实现了 ApplicationEventPublisher 的 publishEvent
- 在这个 publishEvent() 方法中就获取到 所有的 listeners 然后遍历 执行
listener.onApplicationEvent(event);
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于