<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
對於ApplicationListener使用Spring的應該也熟悉,因為這就是我們平時學習的觀察者模式的實際代表。
Spring基於Java提供的EventListener實現了一套以Spring容器為基礎的觀察者模式的事件監聽功能,
用於只要實現Spring提供的介面完成事件的定義和監聽者的定義,那麼就可以很快速的接入觀察者模式的實現。
說ApplicationListener之前先要知道EventListener。
EventListener本身是一個介面,它的作用跟前面講到的Aware類似,都是隻定義最頂級的介面,並沒有實習對應的方法,並且該介面也是由JDK提供的,並不是直接由Spring提供,Spring只是基於該介面實現了自己的一套事件監聽功能。
在Spring中實現事件監聽的介面是ApplicationListener,該介面繼承了EventListener,並做了對應的實現。
原始碼如下:
package java.util; /** * A tagging interface that all event listener interfaces must extend. * @since JDK1.1 */ public interface EventListener { }
@FunctionalInterface public interface ApplicationListener<E extends ApplicationEvent> extends EventListener { //監聽者監聽事件的邏輯處理 void onApplicationEvent(E event); static <T> ApplicationListener<PayloadApplicationEvent<T>> forPayload(Consumer<T> consumer) { return event -> consumer.accept(event.getPayload()); } }
對於ApplicationListener的使用,因為Spring已經做了自己的封裝,並且以Spring容器為基礎做了實現,那麼開發者使用時也可以很快的上手,只要簡單的設定即可。
//事件繼承Spring中的ApplicationEvent public class MyEvent extends ApplicationEvent { private String name; public MyEvent(ApplicationContext source,String name) { super(source); this.name = name; } public String getName() { return name; } }
//定義監聽者實現ApplicationListener,並通過泛型宣告監聽的事件 @Component public class MyEventListener implements ApplicationListener<MyEvent> { @Override public void onApplicationEvent(MyEvent event) { System.out.println("監聽MyEvent:收到訊息時間:"+event.getTimestamp()+"【訊息name:"+event.getName() + "】"); } }
@Component public class MyEventProcessor implements ApplicationContextAware { private ApplicationContext applicationContext; @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } public ApplicationContext getApplicationContext() { return applicationContext; } }
@SpringBootApplication public class BootApplication { @Resource private DefaultListableBeanFactory defaultListableBeanFactory; @Resource private MySpringAware mySpringAware; @Resource private MyEventProcessor myEventProcessor; public static void main(String[] args) { SpringApplication.run(BootApplication.class,args); } @PostConstruct public void init() { ApplicationContext applicationContext = myEventProcessor.getApplicationContext(); //釋出事件,事件釋出之後,前面訂閱的監聽者就會監聽到該事件釋出的訊息 applicationContext.publishEvent(new MyEvent(applicationContext,"陳湯姆")); applicationContext.publishEvent(new MyEvent(applicationContext,"陳湯姆2")); } }
從以上的例子中可以看到ApplicationListner的模式就是設計模式中的觀察者模式。
觀察者模式的作用很好的解決了同步互動的問題。
以傳送者和接收者為例,接收者接收訊息如果同步場景下需要與傳送者實現同步呼叫,但是這樣就導致兩者之間無法解耦,而ApplicationListener就是解決同步的問題,ApplicationListener可以提供半解耦的方式實現兩者之間的互動,即傳送者傳送訊息不需要與接收者之間實現同步通知,只要訂閱傳送者的事件即可完成雙發的互動。
這裡為什麼是半解耦,因為兩者之間還是有一定互動的,互動的點就在於傳送者的傳送方需要維護一個接收者的集合,傳送方在傳送時需要將具體的接收者放在集合中,在傳送時通過遍歷集合傳送給接收方,執行接收方的業務處理。
在ApplicationListener這個集合就是public final Set<ApplicationListener<?>> applicationListeners = new LinkedHashSet<>(); 這個集合中就儲存了接收者的範例,最終會遍歷該集合執行接收者的業務邏輯。
這裡拋一個問題,其實ApplicationListener的功能通過MQ也可以實現,那麼觀察者模式和釋出訂閱模式的區別是什麼呢?歡迎評論區一起討論!
對於ApplicationListener的註冊比較好梳理的,只要找到儲存ApplicationListener的集合就可以知道怎麼add集合的。
在Spring中ApplicationListener的註冊也是在Spring中實現的。
具體的梳理邏輯如下:
org.springframework.context.support.AbstractApplicationContext#refresh
org.springframework.context.support.AbstractApplicationContext#registerListeners
org.springframework.context.event.AbstractApplicationEventMulticaster#addApplicationListener
原始碼梳理如下:
public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext { @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(); //註冊觀察者 registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } } //將觀察者注入到集合中 protected void registerListeners() { // Register statically specified listeners first. for (ApplicationListener<?> listener : getApplicationListeners()) { getApplicationEventMulticaster().addApplicationListener(listener); } // Do not initialize FactoryBeans here: We need to leave all regular beans // uninitialized to let post-processors apply to them! String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false); for (String listenerBeanName : listenerBeanNames) { //呼叫集合的add操作 getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName); } // Publish early application events now that we finally have a multicaster... Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents; this.earlyApplicationEvents = null; if (earlyEventsToProcess != null) { for (ApplicationEvent earlyEvent : earlyEventsToProcess) { //獲取觀察者的集合 getApplicationEventMulticaster().multicastEvent(earlyEvent); } } } }
public abstract class AbstractApplicationEventMulticaster implements ApplicationEventMulticaster, BeanClassLoaderAware, BeanFactoryAware { private class ListenerRetriever { //儲存觀察者的集合 public final Set<ApplicationListener<?>> applicationListeners = new LinkedHashSet<>(); public final Set<String> applicationListenerBeans = new LinkedHashSet<>(); private final boolean preFiltered; public ListenerRetriever(boolean preFiltered) { this.preFiltered = preFiltered; } //獲取觀察者的集合 public Collection<ApplicationListener<?>> getApplicationListeners() { List<ApplicationListener<?>> allListeners = new ArrayList<>( this.applicationListeners.size() + this.applicationListenerBeans.size()); allListeners.addAll(this.applicationListeners); if (!this.applicationListenerBeans.isEmpty()) { BeanFactory beanFactory = getBeanFactory(); for (String listenerBeanName : this.applicationListenerBeans) { try { ApplicationListener<?> listener = beanFactory.getBean(listenerBeanName, ApplicationListener.class); if (this.preFiltered || !allListeners.contains(listener)) { allListeners.add(listener); } } catch (NoSuchBeanDefinitionException ex) { // Singleton listener instance (without backing bean definition) disappeared - // probably in the middle of the destruction phase } } } if (!this.preFiltered || !this.applicationListenerBeans.isEmpty()) { AnnotationAwareOrderComparator.sort(allListeners); } return allListeners; } } }
從以上的原始碼可以看到核心的集合就是applicationListeners。可以根據該集合梳理註冊和執行流程。
註冊梳理清晰,那麼執行自然也很好梳理了, 畢竟使用的都是同一個集合。
ApplicationListener的執行其實就是觀察者的執行,也就是在使用篇章中的MyEventListener,在MyEventListener中重寫了onApplicationEvent,其中實現了自己的邏輯,那麼執行就是將MyEventListener中重寫的方式如何在沒有同步呼叫的情況下執行。
執行的實現就是依賴觀察者的集合,在註冊中我們已經將所有的觀察者新增到了ApplicationListener集合中,只要將該集合中的觀察者取出執行,即可完成半解耦的執行。
梳理流程如下:
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.event.SimpleApplicationEventMulticaster#multicastEvent(org.springframework.context.ApplicationEvent, org.springframework.core.ResolvableType)
org.springframework.context.event.SimpleApplicationEventMulticaster#invokeListener
org.springframework.context.event.SimpleApplicationEventMulticaster#doInvokeListener
原始碼如下:
public class SimpleApplicationEventMulticaster extends AbstractApplicationEventMulticaster { @Override public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) { ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event)); //getApplicationListeners就是獲取ApplicationListener的集合 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); } } //最終執行邏輯 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.isDebugEnabled()) { logger.debug("Non-matching event type for listener: " + listener, ex); } } else { throw ex; } } } }
從以上的梳理中,對ApplicationListener的邏輯做一個總結,對於ApplicationListener整體邏輯梳理如下:
以上就是自己關於Spring中ApplicationListener的理解,更多關於Spring ApplicationListener的資料請關注it145.com其它相關文章!
相關文章
<em>Mac</em>Book项目 2009年学校开始实施<em>Mac</em>Book项目,所有师生配备一本<em>Mac</em>Book,并同步更新了校园无线网络。学校每周进行电脑技术更新,每月发送技术支持资料,极大改变了教学及学习方式。因此2011
2021-06-01 09:32:01
综合看Anker超能充系列的性价比很高,并且与不仅和iPhone12/苹果<em>Mac</em>Book很配,而且适合多设备充电需求的日常使用或差旅场景,不管是安卓还是Switch同样也能用得上它,希望这次分享能给准备购入充电器的小伙伴们有所
2021-06-01 09:31:42
除了L4WUDU与吴亦凡已经多次共事,成为了明面上的厂牌成员,吴亦凡还曾带领20XXCLUB全队参加2020年的一场音乐节,这也是20XXCLUB首次全员合照,王嗣尧Turbo、陈彦希Regi、<em>Mac</em> Ova Seas、林渝植等人全部出场。然而让
2021-06-01 09:31:34
目前应用IPFS的机构:1 谷歌<em>浏览器</em>支持IPFS分布式协议 2 万维网 (历史档案博物馆)数据库 3 火狐<em>浏览器</em>支持 IPFS分布式协议 4 EOS 等数字货币数据存储 5 美国国会图书馆,历史资料永久保存在 IPFS 6 加
2021-06-01 09:31:24
开拓者的车机是兼容苹果和<em>安卓</em>,虽然我不怎么用,但确实兼顾了我家人的很多需求:副驾的门板还配有解锁开关,有的时候老婆开车,下车的时候偶尔会忘记解锁,我在副驾驶可以自己开门:第二排设计很好,不仅配置了一个很大的
2021-06-01 09:30:48
不仅是<em>安卓</em>手机,苹果手机的降价力度也是前所未有了,iPhone12也“跳水价”了,发布价是6799元,如今已经跌至5308元,降价幅度超过1400元,最新定价确认了。iPhone12是苹果首款5G手机,同时也是全球首款5nm芯片的智能机,它
2021-06-01 09:30:45