spring boot 源码赏析之事件监听

使用spring Boot已经快1年多了，期间一直想点开springboot源码查看，但由于种种原因一直未能如愿（主要是人类的惰性。。。），今天就拿springboot 的监听事件祭刀。

springboot 中常用的事件监听主要有ApplicationStartedEvent,ApplicationEnviromentPreparedEvent,ApplicationPreparedEvent,ApplicationStoppedEvent等。用于监听springboot生命周期中的各种事件。

说到监听都会不由自主想到观察者模式，springboot的事件监听实现也没出意外，它的实现机制也是一个典型的观察者模式，只不过稍微复杂点罢了。springboot将观察者放入一个list中委托

 SimpleApplicationEventMulticaster管理。这里有个有意思的地方，srpingboot在实例化SpringApplicationRunListener 时并没有通过正常的途径（比如new，或者其他实例化方法），而是将接口的实现类交由

SpringFactoriesLoader去 META-INF/spring.factories 下装载：

public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
        String factoryClassName = factoryClass.getName();
        try {
            Enumeration<URL> urls = (classLoader != null ? classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
                    ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
            List<String> result = new ArrayList<String>();
            while (urls.hasMoreElements()) {
                URL url = urls.nextElement();
                Properties properties = PropertiesLoaderUtils.loadProperties(new UrlResource(url));
                String factoryClassNames = properties.getProperty(factoryClassName);
                result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));
            }
            return result;
        }
        catch (IOException ex) {
            throw new IllegalArgumentException("Unable to load [" + factoryClass.getName() +
                    "] factories from location [" + FACTORIES_RESOURCE_LOCATION + "]", ex);
        }
    }

这里通过classLoader的getResources方法将所有的META-INF/spring.factories资源都装载进来。

springboot为什么要不惜花费这么大代价去装载一个接口的实现呢，稍微分析一下还是很清晰的，首先，将接口和实现分离，这是典型的依赖注入，如果从单个应用程序来看，大不必这样。关键就在SpringFactoriesLoader里，如上所说，SpringFactoriesLoader是将所有的配置都装载进来，也就是说springboot在为以后的扩展留了条后路，当有新的jar包(意味着又升级啦)加进来，并且需要添加新的的监听事件类型时，就不用修改原有的代码。这就是传说中的对修改关闭对扩展开放的典型例子。

接着说，那么SpringFactoriesLoader装载的实例到底是什么呢， EventPublishingRunListener！

这货也就是个中间类，承接了事件的管理和事件的广播，正真的主角是SimpleApplicationEventMulticaster类，该类的实例在EventPublishingRunListener实例化时被创建出来。

里面有个ListenerRetriever内部类，这个类有两个作用，一个default，SimpleApplicationEventMulticaster初始化时被创建，含有所有的观察者，并作为各种操作的同步锁，还有就是将观察者分类，分类的依据有两个，

一个是事件类型eventType,还有一个是事件原始对象类型sourceType,sourceType是每个事件都会有的，这里是applicationContext。，分类好后，会在事件发生时由最上层SpringApplication发起通知，最后由SimpleApplicationEventMulticaster对象分别调用每个具体的观察者：

protected void invokeListener(ApplicationListener listener, ApplicationEvent event) {
        ErrorHandler errorHandler = getErrorHandler();
        if (errorHandler != null) {
            try {
                listener.onApplicationEvent(event);
            }
            catch (Throwable err) {
                errorHandler.handleError(err);
            }
        }
        else {
            try {
                listener.onApplicationEvent(event);
            }
            catch (ClassCastException ex) {
                String msg = ex.getMessage();
                if (msg == null || msg.startsWith(event.getClass().getName())) {
                    // Possibly a lambda-defined listener which we could not resolve the generic event type for
                    Log logger = LogFactory.getLog(getClass());
                    if (logger.isDebugEnabled()) {
                        logger.debug("Non-matching event type for listener: " + listener, ex);
                    }
                }
                else {
                    throw ex;
                }
            }
        }
    }

至此，一个完整的从事件注册到事件出发再到事件执行完毕的流程结束。山路十八弯，沿途风景多，细细品味还是会有一番收获的。这当中仍有许多细节未能一一道出，比如hashmap的hashCode的重写分析，比如同步锁的使用原因等等。

                                                                                                                                                     转载请注明出处。