大家對ApplicationListener應該不會陌生,但是大家是否了解Spring事件監聽機制是怎么實現的呢?讓我們一起來看源碼!
Spring的事件監聽機制是觀察者模式的一個典型應用,觀察者模式試圖定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時,所有依賴于它的對象都得到通知并被自動更新。
首先我們明確事件監聽的三個要素:事件、事件監聽器、事件源。
在spring的事件監聽機制中,ApplicationEvent充當事件的角色。所有的事件都要繼承ApplicationEvent。
public abstract class ApplicationEvent extends EventObject {
/** use serialVersionUID from Spring 1.2 for interoperability. */
private static final long serialVersionUID = 7099057708183571937L;
/** System time when the event happened. */
private final long timestamp;
/**
* Create a new ApplicationEvent.
* @param source the object on which the event initially occurred (never {@code null})
*/
public ApplicationEvent(Object source) {
super(source);
this.timestamp = System.currentTimeMillis();
}
ApplicationListener充當事件監聽器的角色,當事件發生時,進行對應的操作。它對應著觀察者模式中的觀察者Observer。當監聽的事件發生后該方法會被執行。
@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
/**
* Handle an application event.
* @param event the event to respond to
*/
void onApplicationEvent(E event);
}
事件源是事件發起的地方,ApplicationEventPublisher接口下的方法就是發布事件的,實現該接口便可以作為事件源,AbstractApplicationContext實現了該接口,在finishRefresh()方法中就會調用publishEvent()方法發布事件。
@FunctionalInterface
public interface ApplicationEventPublisher {
/**
* Notify all <strong>matching</strong> listeners registered with this
* application of an application event. Events may be framework events
* (such as RequestHandledEvent) or application-specific events.
* @param event the event to publish
* @see org.springframework.web.context.support.RequestHandledEvent
*/
default void publishEvent(ApplicationEvent event) {
publishEvent((Object) event);
}
/**
* Notify all <strong>matching</strong> listeners registered with this
* application of an event.
* <p>If the specified {@code event} is not an {@link ApplicationEvent},
* it is wrapped in a {@link PayloadApplicationEvent}.
* @param event the event to publish
* @since 4.2
* @see PayloadApplicationEvent
*/
void publishEvent(Object event);
}
從一個簡單的例子開始分析源碼
定義一個MyConfigApplicationContext繼承與AnnotationConfigApplicationContext
public class MyConfigApplicationContext extends AnnotationConfigApplicationContext {
public MyConfigApplicationContext(Class c) {
super(c);
}
@Override
protected void onRefresh() throws BeansException {
this.publishEvent(new ApplicationEvent("我手動發布了一個事件") {
@Override
public Object getSource() {
return super.getSource();
}
});
super.onRefresh();
}
}
我們先不討論為何要這樣寫,繼續寫配置類
@Configuration
@ComponentScan(basePackages = {"com.example.demo"})
public class MainConfig {
}
然后主類
public class DemoApplication {
public static void main(String[] args) {
MyConfigApplicationContext ctx = new MyConfigApplicationContext(MainConfig.class);
}
}
運行一下
順著這個跟蹤一下源碼
可以看到在創建自定義的bean之前監聽器已經監聽到事件發生了,所以我們從ApplicationContext的構造器開始看起
public AnnotationConfigApplicationContext(Class<?>... annotatedClasses) {
//創建關鍵組件
this();
//注冊配置類MainConfig的bean定義(BeanDefinition),此時還未實例化bean
register(annotatedClasses);
refresh();
}
重點看refresh()方法
@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
initMessageSource();
// Initialize event multicaster for this context.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
onRefresh();
// Check for listener beans and register them.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
finishRefresh();
}
可以看到initApplicationEventMulticaster()方法,看這名字就覺得跟事件監聽的有關,該方法初始化事件廣播器。
protected void initApplicationEventMulticaster() {
//先獲取beanFactory
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
//看看是否有applicationEventMulticaster這個bean存在
if (beanFactory.containsLocalBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME)) {
this.applicationEventMulticaster =
beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class);
if (logger.isTraceEnabled()) {
logger.trace("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]");
}
}
else {
//創建一個SimpleApplicationEventMulticaster,并注冊到容器中
this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);
beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster);
if (logger.isTraceEnabled()) {
logger.trace("No '" + APPLICATION_EVENT_MULTICASTER_BEAN_NAME + "' bean, using " +
"[" + this.applicationEventMulticaster.getClass().getSimpleName() + "]");
}
}
}
然后看registerListeners()方法,明顯也跟事件監聽有關
protected void registerListeners() {
//去容器中把applicationListener 撈取出來注冊到廣播器上去(系統的)
for (ApplicationListener<?> listener : getApplicationListeners()) {
getApplicationEventMulticaster().addApplicationListener(listener);
}
//注冊我們自己實現了ApplicationListener 的組件
String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
for (String listenerBeanName : listenerBeanNames) {
getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
}
// 發布早期事件(防止某些事件出現在廣播器還沒有初始化的時候,漏掉該部分事件)
Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
this.earlyApplicationEvents = null;
if (earlyEventsToProcess != null) {
for (ApplicationEvent earlyEvent : earlyEventsToProcess) {
//廣播器廣播早期事件
getApplicationEventMulticaster().multicastEvent(earlyEvent);
}
}
}
容器在registerListeners()方法之前publishEvent的都是早期事件,所以我們重寫了onRefresh()方法,并在其中發布了一個事件,該事件為早期事件,然后在registerListeners時,被廣播器廣播到監聽器。
finishRefresh()方法中有發布事件。
protected void finishRefresh() {
// Clear context-level resource caches (such as ASM metadata from scanning).
clearResourceCaches();
// Initialize lifecycle processor for this context.
initLifecycleProcessor();
// Propagate refresh to lifecycle processor first.
getLifecycleProcessor().onRefresh();
// Publish the final event.
publishEvent(new ContextRefreshedEvent(this));
// Participate in LiveBeansView MBean, if active.
LiveBeansView.registerApplicationContext(this);
}
protected void publishEvent(Object event, @Nullable ResolvableType eventType) {
Assert.notNull(event, "Event must not be null");
// Decorate event as an ApplicationEvent if necessary
ApplicationEvent applicationEvent;
//支持兩種類型的事件
//1、直接繼承ApplicationEven
//2、其他事件,會被包裝為PayloadApplicationEvent,可以使用getPayload獲取真實的通知內容
if (event instanceof ApplicationEvent) {
applicationEvent = (ApplicationEvent) event;
}
else {
applicationEvent = new PayloadApplicationEvent<>(this, event);
if (eventType == null) {
eventType = ((PayloadApplicationEvent<?>) applicationEvent).getResolvableType();
}
}
// 如果earlyApplicationEvents不為空,便把事件加入到早期事件集合中
if (this.earlyApplicationEvents != null) {
this.earlyApplicationEvents.add(applicationEvent);
}
else {
//廣播事件
getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
}
// 如果設置了父容器,父容器同樣發布事件
if (this.parent != null) {
if (this.parent instanceof AbstractApplicationContext) {
((AbstractApplicationContext) this.parent).publishEvent(event, eventType);
}
else {
this.parent.publishEvent(event);
}
}
}
那什么時候earlyApplicationEvents不為空,什么時候為空呢?
可以看到在refresh()方法執行perpareRefresh()方法時,實例化earlyApplicationEvents集合,所以在此方法執行后發布的事件會被加入早期事件集合,到執行registerListeners方法,該方法會廣播早期事件,而且把earlyApplicationEvents設置為null,所以在registerListeners后發布的事件不是早期事件,廣播器直接廣播。
看下SimpleApplicationEventMulticaster.multicastEvent方法,看看其是如何廣播的
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
//獲取事件類型,如:org.springframework.boot.context.event.ApplicationStartingEvent
ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
//獲取監聽該事件的監聽器,并循環每個監聽器
for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {
Executor executor = getTaskExecutor();
//是否異步執行
if (executor != null) {
executor.execute(() -> invokeListener(listener, event));
}
else {
invokeListener(listener, event);
}
}
}
multicastEvent()方法里面調用了invokeListener()
protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
ErrorHandler errorHandler = getErrorHandler();
//是否設置了錯誤處理器
if (errorHandler != null) {
try {
doInvokeListener(listener, event);
}
catch (Throwable err) {
errorHandler.handleError(err);
}
}
else {
doInvokeListener(listener, event);
}
}
private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
try {
//可以看到回調了監聽器的onApplicationEvent()方法,典型的觀察者設計模式
//廣播器持有監聽器(觀察者),然后在事件發生時,廣播器回調監聽器的方法
listener.onApplicationEvent(event);
}
catch (ClassCastException ex) {
String msg = ex.getMessage();
if (msg == null || matchesClassCastMessage(msg, event.getClass())) {
// Possibly a lambda-defined listener which we could not resolve the generic event type for
// -> let's suppress the exception and just log a debug message.
Log logger = LogFactory.getLog(getClass());
if (logger.isTraceEnabled()) {
logger.trace("Non-matching event type for listener: " + listener, ex);
}
}
else {
throw ex;
}
}
}
而廣播器廣播其實就是觀察者模式,廣播器持有監聽器,在廣播時回調監聽器的onApplicationEvent()方法。過程如下圖:
這就是spring事件監聽機制的大致流程。
可以看到初始化廣播器的時候,會先從容器中獲取 applicationEventMulticaster 的 bean。
protected void initApplicationEventMulticaster() {
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (beanFactory.containsLocalBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME)) {
this.applicationEventMulticaster =
beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class);
if (logger.isTraceEnabled()) {
logger.trace("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]");
}
}
else {
this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);
beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster);
if (logger.isTraceEnabled()) {
logger.trace("No '" + APPLICATION_EVENT_MULTICASTER_BEAN_NAME + "' bean, using " +
"[" + this.applicationEventMulticaster.getClass().getSimpleName() + "]");
}
}
}
由此可見我們可以自己注入一個 applicationEventMulticaster bean。例如:
@Configuration
@ComponentScan(basePackages = {"com.example.demo"})
public class MainConfig {
@Autowired
private Executor syncTaskExecutor;
@Bean("applicationEventMulticaster")
public AbstractApplicationEventMulticaster applicationEventMulticaster() {
SimpleApplicationEventMulticaster abstractApplicationEventMulticaster = new SimpleApplicationEventMulticaster();
abstractApplicationEventMulticaster.setTaskExecutor(syncTaskExecutor);
return abstractApplicationEventMulticaster;
}
}
這樣監聽器就會異步處理事件。
@Override
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {
Executor executor = getTaskExecutor();
if (executor != null) {
executor.execute(() -> invokeListener(listener, event));
}
else {
invokeListener(listener, event);
}
}
}
protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
ErrorHandler errorHandler = getErrorHandler();
if (errorHandler != null) {
try {
doInvokeListener(listener, event);
}
catch (Throwable err) {
errorHandler.handleError(err);
}
}
else {
doInvokeListener(listener, event);
}
}