ApplicationListener原理分析

在 Nacos配置服务原理 文中结束时提到过通过发布 ApplicationListener 刷新事件完成 Context 中属性值的更新。那么本章我们一起分析 ApplicationListener 原理。在开启 ApplicationListener 解析之前我们先看一个传说中模式----观察者模式(Observer)。

观察者模式

观察者模式定义：对象间一种一对多的依赖关系，当一个被观察的对象改变状态，则会自动通知它的依赖对象。观察者模式属于行为型模式。这是比较概念性的定义，下面我用一种接近生活的例子来诠释观察者模式。上大学的时候，很多学生经常旷课，但是快到期末考试那两三节课基本是全到的，为什么呢？不错，老师会划考试重点！！！这时老师就是被学生观察的对象，学生就是观察者。当老师说以下这个知识点考试会考时，下面刷刷刷响起来，同学们都在用笔画标记！当然不同的学生用的办法不一样，比如学霸会用五颜六色的表把重中之重区分出来，学渣可能就不管全用2B铅笔画（我就是这学渣中的其一）。看一下老师和学生的关系图：

郑重声明一下，本学渣比较懒，没有自己实现一个观察者模式，直接用的是jdk提供的Observer和Obervable。接下来直接用代码说明一切。

被观察对象

/**
 * 被观察对象
 * @author Greiz
 */
public class TeacherObservable extends Observable {
    private String examKeyPoints;
    public String getExamKeyPoints() {
        return examKeyPoints;
    }
    public void setExamKeyPoints(String examKeyPoints) {
        this.examKeyPoints = examKeyPoints;
        // 修改状态
        super.setChanged();
        // 通知所有观察者
        super.notifyObservers(examKeyPoints);
    }
}

被观察对象（老师），继承了Observable。当变量考试重点（examKeyPoints）变了通知观察者

public class Observable {
    private boolean changed = false;
    private Vector<Observer> obs;
    public synchronized void addObserver(Observer o) {
        if (o == null)
            throw new NullPointerException();
        if (!obs.contains(o)) {
            obs.addElement(o);
        }
    }
    public void notifyObservers() {
        notifyObservers(null);
    }
    public void notifyObservers(Object arg) {
        Object[] arrLocal;
        synchronized (this) {
            if (!changed)
                return;
            arrLocal = obs.toArray();
            clearChanged();
        }
        for (int i = arrLocal.length-1; i>=0; i--)
            ((Observer)arrLocal[i]).update(this, arg);
    }
    protected synchronized void setChanged() {
        changed = true;
    }  
}

JDK中的Observable类。成员变量维护一个观察者的列表，通知的时候遍历该列表逐个调用update()方法。哈哈，是不是很简单。

观察者

public interface Observer {
    void update(Observable o, Object arg);
}

监听者用的也是JDK的，这家伙比我还懒，就一个方法的接口，要干的活都交给后代处理。

/**
 * @author Greiz
 */
public class ExcellentStudentObserver implements Observer {
    public static final String STUDENT = "我学霸";
    @Override
    public void update(Observable o, Object arg) {
        System.out.println(STUDENT + "用各种颜色的笔划重点:" + arg.toString());
    }
}

监听者 -- 学霸，当TeacherObservable成员变量改变时最终会调该类的update()方法。

/**
 * @author Greiz
 */
public class PoorStudentObserver implements Observer {
    public static final String STUDENT = "我学渣一枚";
    @Override
    public void update(Observable o, Object arg) {
        System.out.println(STUDENT + "用2B铅笔划重点:" + arg.toString());
    }
}

监听者 -- 学渣（我），当TeacherObservable成员变量改变时最终会调该类的update()方法。

管理者

老师和学生都有了，剩下的就差把他们联系起来了，总不能随手一把抓吧，专业不对口划重点也没有啊！

/**
 * @author Greiz
 */
public class ObserverManager {
    public static void main(String[] args) {
        TeacherObservable observable = new TeacherObservable();
        // 给被观察者对象添加观察者
        observable.addObserver(new PoorStudentObserver());
        observable.addObserver(new ExcellentStudentObserver());
        // 修改被观察者
        observable.setExamKeyPoints("这是考试重点！！！");
    }
}

一个简单的观察者模式完整的列子完成了。

小结

优点

1. 被观察对象和观察者之间解耦。

2. 建立回调机制模型。

缺点

1. 如果被观察对象维护的观察者列表中成员过多，遍历通知会耗时相当长。
   2. 如果被观察对象和观察者之间出现相互调用容易形成死循环。
   3. 观察者不清楚被观察者对象变化的细节
   4. 只能本地，不能分布式。

ApplicationListener 源码解析

ApplicationListener 跟上面观察者模式有什么关系呢？我们先看源码，后面一起分析一下他们的关系。这节分两个阶段，一个调用阶段，另一个组装阶段。

调用阶段

下面我画出调用过程一些重要接口调用时序图。

源码解析调用阶段都是围绕这个图步骤进行。

public class GreizEvent extends ApplicationEvent {
    public GreizEvent(Object source) {
        super(source);
    }
    private String name = "Greiz";
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

自定义事件，需要继承 ApplicationEvent。

@Component
public class GreizListener implements ApplicationListener<GreizEvent> {
    @Override
    public void onApplicationEvent(GreizEvent event) {
        System.out.println("=============" + event.getName());
    }
}

添加自定义事件监听者，必须加入Spring容器管理相关注解如 @Component，否则不起作用。

public static void main(String[] args) {
    ApplicationContext context = new AnnotationConfigApplicationContext("com.greiz.demo.listener");
    context.publishEvent(new GreizEvent("Greiz"));
}

启动Spring，发布自定义事件

接下来进入时序图中1-6 接口。

protected void publishEvent(Object event, @Nullable ResolvableType eventType) {
   ApplicationEvent applicationEvent;
   if (event instanceof ApplicationEvent) {
      applicationEvent = (ApplicationEvent) event;
   }
   ... 省略代码
   if (this.earlyApplicationEvents != null) {
      this.earlyApplicationEvents.add(applicationEvent);
   }
   else {
      getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
   }
   ... 省略代码
}

对应时序图方法1， AbstractApplicationContext.publishEvent()。publishEvent方法是在 ApplicationEventPublisher 定义的，ApplicationEventPublisher 可以理解成事件发射器。会调用 getApplicationEventMulticaster()

ApplicationEventMulticaster getApplicationEventMulticaster() throws IllegalStateException {
   if (this.applicationEventMulticaster == null) {
      throw new IllegalStateException("ApplicationEventMulticaster not initialized - " +
            "call 'refresh' before multicasting events via the context: " + this);
   }
   return this.applicationEventMulticaster;
}

对应时序图方法2，AbstractApplicationContext.getApplicationEventMulticaster()获取事件广播者。applicationEventMulticaster 在Spring启动refresh过程 调用 initApplicationEventMulticaster() 初始化，是 SimpleApplicationEventMulticaster 实例。

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

对应时序图方法3，SimpleApplicationEventMulticaster.multicastEvent()。根据事件类型，获取所有对应的监听者，然后遍历通知（俗称广播）。

protected Collection<ApplicationListener<?>> getApplicationListeners(
      ApplicationEvent event, ResolvableType eventType) {
   Object source = event.getSource();
   Class<?> sourceType = (source != null ? source.getClass() : null);
   ListenerCacheKey cacheKey = new ListenerCacheKey(eventType, sourceType);
   ListenerRetriever retriever = this.retrieverCache.get(cacheKey);
   if (retriever != null) {
      return retriever.getApplicationListeners();
   }

   if (this.beanClassLoader == null ||
         (ClassUtils.isCacheSafe(event.getClass(), this.beanClassLoader) &&
               (sourceType == null || ClassUtils.isCacheSafe(sourceType, this.beanClassLoader)))) {
      synchronized (this.retrievalMutex) {
         retriever = this.retrieverCache.get(cacheKey);
         if (retriever != null) {
            return retriever.getApplicationListeners();
         }
         retriever = new ListenerRetriever(true);
         Collection<ApplicationListener<?>> listeners =
               retrieveApplicationListeners(eventType, sourceType, retriever);
         this.retrieverCache.put(cacheKey, retriever);
         return listeners;
      }
   }
   else {
      return retrieveApplicationListeners(eventType, sourceType, null);
   }
}

对应时序图方法4，AbstractApplicationEventMulticaster.getApplicationListeners()。根据事件类型，先查询缓存，如果缓存中没有调用 retrieveApplicationListeners() 获取，然后存到缓存中。

private Collection<ApplicationListener<?>> retrieveApplicationListeners(
      ResolvableType eventType, @Nullable Class<?> sourceType, @Nullable ListenerRetriever retriever) {

   List<ApplicationListener<?>> allListeners = new ArrayList<>();
   Set<ApplicationListener<?>> listeners;
   Set<String> listenerBeans;
   synchronized (this.retrievalMutex) {
      listeners = new LinkedHashSet<>(this.defaultRetriever.applicationListeners);
      listenerBeans = new LinkedHashSet<>(this.defaultRetriever.applicationListenerBeans);
   }
   for (ApplicationListener<?> listener : listeners) {
      if (supportsEvent(listener, eventType, sourceType)) {
         if (retriever != null) {
            retriever.applicationListeners.add(listener);
         }
         allListeners.add(listener);
      }
   }
   if (!listenerBeans.isEmpty()) {
      BeanFactory beanFactory = getBeanFactory();
      for (String listenerBeanName : listenerBeans) {
         try {
            Class<?> listenerType = beanFactory.getType(listenerBeanName);
            if (listenerType == null || supportsEvent(listenerType, eventType)) {
               ApplicationListener<?> listener = beanFactory.getBean(listenerBeanName, ApplicationListener.class);
               if (!allListeners.contains(listener) && supportsEvent(listener, eventType, sourceType)) {
                  if (retriever != null) {
                     if (beanFactory.isSingleton(listenerBeanName)) {
                        retriever.applicationListeners.add(listener);
                     }
                     else {
                        retriever.applicationListenerBeans.add(listenerBeanName);
                     }
                  }
                  allListeners.add(listener);
               }
            }
         }
         catch (NoSuchBeanDefinitionException ex) {
         }
      }
   }
   AnnotationAwareOrderComparator.sort(allListeners);
   if (retriever != null && retriever.applicationListenerBeans.isEmpty()) {
      retriever.applicationListeners.clear();
      retriever.applicationListeners.addAll(allListeners);
   }
   return allListeners;
}

对应时序图方法5，AbstractApplicationEventMulticaster.retrieveApplicationListeners()。 所有事件监听者都在this.defaultRetriever 对象中，该对象的值初始化过程我们在下一节分析。返回过滤后符合本次事件的监听者。接下来我们回到 时序图方法3 中继续调用 SimpleApplicationEventMulticaster.invokeListener()。

	private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
		try {
			listener.onApplicationEvent(event);
		}
		catch (ClassCastException ex) {
			... 省略代码
		}
	}

对应时序图方法6，SimpleApplicationEventMulticaster.doInvokeListener()。 这里就是真正调用监听者的方法。

前面提出 ApplicationListener 跟观察者模式有什么关系呢？分析 publishEvent(...) 到 onApplicationEvent(...) 调用，是不是很像前面观察者模式列子中 setExamKeyPoints() --> notifyObservers() --> update()。这一个阶段可以看作就是观察者模式中调用阶段。接下来我们继续分析观察者和被观察者对象绑定过程---组装阶段。

组装阶段

照旧，以图开篇，接下来全靠编！！！

在调用阶段时序图5中得知符合对应事件的监听者是从 AbstractApplicationEventMulticaster 成员 (ListenerRetriever)defaultRetriever 的 applicationListeners 和 applicationListenerBeans 属性获取的。组装阶段就是解析 defaultRetriever 初始化负值过程。

applicationListenerBeans 初始化负值过程：

public void refresh() throws BeansException, IllegalStateException {
   synchronized (this.startupShutdownMonitor) {
      ... ... 省略代码
      try {
         ... ... 省略代码
         // ListenerRetriever applicationListenerBeans 初始化负值过程在这里面
         registerListeners();

         // ListenerRetriever applicationListeners 初始化负值过程在这里面
         finishBeanFactoryInitialization(beanFactory);
         ... ... 省略代码
      }

      catch (BeansException ex) {
      	... 省略代码
      }
      finally {
      	... 省略代码
      }
   }
}

对应时序图方法1，AbstractApplicationContext.refresh()。省略了一下与本次目的无关的代码。看注释就好，哈哈。

protected void registerListeners() {
   // 初始化阶段getApplicationListeners()返回空列表
   for (ApplicationListener<?> listener : getApplicationListeners()) {
      getApplicationEventMulticaster().addApplicationListener(listener);
   }
	 // 根据bean类型获取
   String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
   for (String listenerBeanName : listenerBeanNames) {
      getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
   }
  ... 省略代码
}

对应时序图方法2，AbstractApplicationContext.registerListeners()。注意看注释，看注释，看注释！！！此处根据bean类型获取，反应了前面 “添加自定义事件监听者，必须加入Spring容器管理相关注解如 @Component，否则不起作用”的说法。

public void addApplicationListenerBean(String listenerBeanName) {
   synchronized (this.retrievalMutex) {
      this.defaultRetriever.applicationListenerBeans.add(listenerBeanName);
      this.retrieverCache.clear();
   }
}

对应时序图方法3，AbstractApplicationEventMulticaster.addApplicationListenerBean()。

AbstractApplicationEventMulticaster 成员 (ListenerRetriever)defaultRetriever 的applicationListenerBeans 属性负值完成。

applicationListeners 初始化负值过程：

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
		... 省略代码
		beanFactory.preInstantiateSingletons();
	}

对应时序图方法4，AbstractApplicationContext.finishBeanFactoryInitialization()。

偷懒一次，跟着这个方法debug下去，最终调用AbstractApplicationContext.addApplicationListener()。

public void addApplicationListener(ApplicationListener<?> listener) {
   Assert.notNull(listener, "ApplicationListener must not be null");
   if (this.applicationEventMulticaster != null) {
      this.applicationEventMulticaster.addApplicationListener(listener);
   }
   this.applicationListeners.add(listener);
}

对应时序图方法14，AbstractApplicationContext.addApplicationListener()。

public void addApplicationListener(ApplicationListener<?> listener) {
   synchronized (this.retrievalMutex) {
      Object singletonTarget = AopProxyUtils.getSingletonTarget(listener);
      if (singletonTarget instanceof ApplicationListener) {
         this.defaultRetriever.applicationListeners.remove(singletonTarget);
      }
      this.defaultRetriever.applicationListeners.add(listener);
      this.retrieverCache.clear();
   }
}

对应时序图方法15，AbstractApplicationEventMulticaster.addApplicationListener()。恩，是不是很熟悉的defaultRetriever。

AbstractApplicationEventMulticaster 成员 (ListenerRetriever)defaultRetriever 的applicationListeners 属性负值完成。

总结

Spring的事件监听者模型可以看作是观察者模式，但Spring对JDK的观察者模式做了扩展，根据事件类型广播给对应的监听者。其实很多Spring源码都是介于JDK的基础上做的扩展，如果把JDK比作生活，那么Spring就是诗人。好诗都是来自生活而高于生活！