1. 簡(jiǎn)單介紹：

事件Event驅(qū)動(dòng)模型實(shí)際也被稱之為觀察者模式，或者發(fā)布/訂閱模型。
Spring中，也為我們提供了這樣的框架，采用Event/Listener這樣的好處自然不用多說(shuō)，就是解耦，利于擴(kuò)展，并且利于一對(duì)多這種形式，我們下面就來(lái)介紹下Spring的Event模式：

2. 核心類：

想要了解Spring的事件模型，需要了解一下幾個(gè)類：

• ApplicationEvent
  事件本身，繼承自Java EventObject。
• ApplicationListener
  監(jiān)聽(tīng)者對(duì)象，能夠選擇監(jiān)聽(tīng)不同的事件Event

public interface ApplicationListener<E extends ApplicationEvent> extends EventListener

• ApplicationEventMulticaster
  事件廣播，也是Spring事件模型中的核心對(duì)象，事件發(fā)布-監(jiān)聽(tīng)依靠的就是ApplicationEventMulticaster，其內(nèi)部類ListenerRetriever按照不同的ApplicationEvent類型對(duì)Listener進(jìn)行了保存，這也是我們?yōu)槭裁茨軌蜥槍?duì)不同的Event進(jìn)行過(guò)濾從而喚醒Listener的過(guò)程。
• ApplicationEventPublisher
  事件的發(fā)布者，通過(guò)ApplicationEventPublisher#publishEvent的方法進(jìn)行事件的廣播。
• ApplicationEventPublisherAware
  獲取ApplicationEventPublisher的方法。
• AbstractApplicationContext
  Spring的事件模型框架的主要邏輯的內(nèi)容出。AbstractApplicationContext中實(shí)現(xiàn)了ApplicationEventPublisher接口，從而實(shí)際在Spring中，默認(rèn)的ApplicationEventPublisher實(shí)現(xiàn)就是AbstractApplicationContext。

3. 例子

我們以如下的情況為例：
以問(wèn)答知乎為例，我們?cè)谛略鲆粋€(gè)問(wèn)題時(shí)，需要異步的去建立索引。而建立索引的過(guò)程由于和新增的邏輯沒(méi)有必然的聯(lián)系，所以可以通過(guò)異步的方式來(lái)進(jìn)行，而這種事件的方式能夠很好的進(jìn)行解耦，或者異步來(lái)執(zhí)行，所以我們可以采用事件驅(qū)動(dòng)來(lái)實(shí)現(xiàn)。

// QuestionEvent
public class QuestionEvent extends ApplicationEvent {
    private String question;
    public String getQuestion() {
        return question;
    }
    public void setQuestion(String question) {
        this.question = question;
    }
    public QuestionEvent(String question) {
        super(question);
        this.question = question;
    }
}

// QuestionListener
@Component("questionListener")
public class QuestionListener implements ApplicationListener<QuestionEvent> {
    public void onApplicationEvent(QuestionEvent questionEvent) {
        System.out.println("index question : " + questionEvent.getQuestion());
    }
}

// EventPublisher
@Component(value = "eventPublisher")
public class EventPublisher implements ApplicationEventPublisherAware {

    private ApplicationEventPublisher applicationEventPublisher;

    public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public ApplicationEventPublisher getApplicationEventPublisher() {
        return applicationEventPublisher;
    }
}

// EventTest
public class EventTest extends BaseTestNG {

    @Resource
    private ApplicationEventPublisher applicationEventPublisher;

    @Test
    public void testEvent() {
        String question = "這是一個(gè)問(wèn)題";
        applicationEventPublisher.publishEvent(new QuestionEvent(question));
    }
}

輸出：
index question : 這是一個(gè)問(wèn)題

4. 源碼分析：

在分析源碼之前，我們首先要明白Event-Listener模式實(shí)際就是觀察者模式。如果看過(guò)之前寫(xiě)過(guò)的觀察者的模式的文章，將會(huì)對(duì)源碼的內(nèi)容較容易明白。
首先是Listener的注冊(cè):
我們定義了Listener(實(shí)現(xiàn)了ApplicationListener)，那又是什么時(shí)候被注冊(cè)到BeanFactory中呢，如果了解Spring的Bean的生命周期的話，會(huì)知道BeanPostProcess是在AbstractApplicationContext的refresh時(shí)候被實(shí)例化并初始化的，這個(gè)過(guò)程是要由于非lazy-init Bean的實(shí)例化過(guò)程的。而實(shí)際，Listener的注冊(cè)過(guò)程也是處在refresh的過(guò)程中的，我們來(lái)看AbstractApplicationContext#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();

                // 初始化傳播器
                initApplicationEventMulticaster();

                // Initialize other special beans in specific context subclasses.
                onRefresh();

                // 注冊(cè)監(jiān)聽(tīng)器
                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();
            }
        }
    }

上面代碼中，與Event有關(guān)的是兩個(gè)內(nèi)容，第一個(gè)是initApplicationEventMulticaster()，用于初始化事件傳播器，而第二個(gè)registerListeners()，便是注冊(cè)監(jiān)聽(tīng)器，實(shí)際就是掃描實(shí)現(xiàn)了ApplicationListener接口的類并注冊(cè)到事件傳播器。
我們來(lái)看InitApplicationEventMulticaster:

    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.isDebugEnabled()) {
                logger.debug("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]");
            }
        }
        else {
            this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);
            beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster);
            if (logger.isDebugEnabled()) {
                logger.debug("Unable to locate ApplicationEventMulticaster with name '" +
                        APPLICATION_EVENT_MULTICASTER_BEAN_NAME +
                        "': using default [" + this.applicationEventMulticaster + "]");
            }
        }
    }

做的內(nèi)容就是一件事，如果容器中沒(méi)有name=“applicationEventMulticaster”的類，則認(rèn)為沒(méi)有自定義的ApplicationEventMulticaster，此時(shí)會(huì)自己new一個(gè)SimpleApplicationEventMulticaster。

那我們來(lái)看看這個(gè)默認(rèn)的廣播器的實(shí)現(xiàn)SimpleApplicationEventMulticaster，其中核心的方法是multicastEvent，從字面來(lái)看是多路廣播事件的意思：

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);
        }
    }

    @SuppressWarnings({"unchecked", "rawtypes"})
    private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
        try {
            listener.onApplicationEvent(event);
        }
        catch (ClassCastException ex) {
            String msg = ex.getMessage();
            if (msg == null || matchesClassCastMessage(msg, event.getClass().getName())) {
                // 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;
            }
        }
    }

可見(jiàn)multicastEvent是獲取對(duì)應(yīng)的Event的listener，并進(jìn)行調(diào)用的，也就是listener.onApplicationEvent(event)。在這里面有點(diǎn)需要注意的是在進(jìn)行調(diào)用的時(shí)候，我們會(huì)先去獲得Executor executor = getTaskExecutor();但是如果我們使用的是默認(rèn)的Executor的話，則實(shí)際executor = null，則此時(shí)喚醒的是同步的，如果我們希望采用多線程的方式，則實(shí)際需要配置自己事件傳播器，并通過(guò)setter的方式將executor配置進(jìn)去。
而關(guān)于SimpleApplicationEventMulticaster是如何將Listener配置進(jìn)去的，下面的代碼顯示了細(xì)節(jié)：

public abstract class AbstractApplicationEventMulticaster
        implements ApplicationEventMulticaster, BeanClassLoaderAware, BeanFactoryAware {

    final Map<ListenerCacheKey, ListenerRetriever> retrieverCache = new ConcurrentHashMap<>(64);
...
private class ListenerRetriever {

        public final Set<ApplicationListener<?>> applicationListeners;

        public final Set<String> applicationListenerBeans;

        private final boolean preFiltered;

        public ListenerRetriever(boolean preFiltered) {
            this.applicationListeners = new LinkedHashSet<>();
            this.applicationListenerBeans = new LinkedHashSet<>();
            this.preFiltered = preFiltered;
        }

        public Collection<ApplicationListener<?>> getApplicationListeners() {
            LinkedList<ApplicationListener<?>> allListeners = new LinkedList<>();
            for (ApplicationListener<?> listener : this.applicationListeners) {
                allListeners.add(listener);
            }
            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
                    }
                }
            }
            AnnotationAwareOrderComparator.sort(allListeners);
            return allListeners;
        }
    }
...

}

在AbstractApplicationEventMulticaster中定義了一個(gè)內(nèi)部類ListenerRetriever，實(shí)際ListenerRetriever對(duì)應(yīng)的是同一類ApplicationEvent的事件監(jiān)聽(tīng)器，而通過(guò)了一個(gè)Map當(dāng)做緩存來(lái)取得相應(yīng)的Listener。
每次獲取的時(shí)候，會(huì)根據(jù)EventType和SourceType來(lái)生成相應(yīng)的ListenerCacheKey，從而獲得相應(yīng)的監(jiān)聽(tīng)器。

5. 定義有序的監(jiān)聽(tīng)器：

如果我們希望監(jiān)聽(tīng)器有序的話，實(shí)際只要實(shí)現(xiàn)SmartApplicationListener接口即可。

6. 參考文章：

詳解Spring事件驅(qū)動(dòng)模型
Spring源碼