接上文，下面是第二次扫描的XML配置。

查看init()方法，会调用DisconfMgr的secondScan()方法。

protected synchronized void secondScan() {    // 上面是顺序的校验    try {        // 扫描回调函数        if (scanMgr != null) {            scanMgr.secondScan();        }        // 注入数据至配置实体中        // 获取数据/注入/Watch        if (disconfCoreMgr != null) {            disconfCoreMgr.inject2DisconfInstance();        }    } catch (Exception e) {        LOGGER.error(e.toString(), e);    }    isSecondInit = true;}

scanMgr是扫描处理器，调用第二次扫描的secondScan()方法。主要处理如下

// 将回调函数实例化并写入仓库ScanDynamicStoreAdapter.scanUpdateCallbacks(scanModel, registry);

ScanDynamicStoreAdapter是动态扫描与Store模块的转换器。下面主要对回调函数的处理。

// ScanStaticModel是第一次扫描结束得到的静态配置存储的对象public static void scanUpdateCallbacks(ScanStaticModel scanModel, Registry registry) {    // 扫描出来    ScanDynamicModel scanDynamicModel = analysis4DisconfUpdate(scanModel, registry);    // 写到仓库中    transformUpdateService(scanDynamicModel.getDisconfUpdateServiceInverseIndexMap());    transformPipelineService(scanDynamicModel.getDisconfUpdatePipeline());}

analysis4DisconfUpdate()会将配置中和回调相关的配置扫描处理。

private static ScanDynamicModel analysis4DisconfUpdate(ScanStaticModel scanModel, Registry registry) {    // 配置项或文件，DisconfKey通过配置类型和名称来标记一个配置key    Map
    
     > inverseMap = new HashMap
     
      >();    // disconfUpdateService是第一次扫描和回调相关的配置，@DisconfUpdateService注解    Set
      
       > disconfUpdateServiceSet = scanModel.getDisconfUpdateService();    for (Class
        disconfUpdateServiceClass : disconfUpdateServiceSet) {        // 回调对应的参数        DisconfUpdateService disconfUpdateService =                disconfUpdateServiceClass.getAnnotation(DisconfUpdateService.class);        // 校验是否有继承正确,是否继承IDisconfUpdate        if (!ScanVerify.hasIDisconfUpdate(disconfUpdateServiceClass)) {            continue;        }        // 获取回调接口实例        IDisconfUpdate iDisconfUpdate = getIDisconfUpdateInstance(disconfUpdateServiceClass, registry);        if (iDisconfUpdate == null) {            continue;        }        // 主要逻辑，将DisconfKey作为key、回调接口作为list vlaue，存入到inverseMap中        // 配置项        processItems(inverseMap, disconfUpdateService, iDisconfUpdate);        //        // 配置文件        processFiles(inverseMap, disconfUpdateService, iDisconfUpdate);    }    // set data，存储所有和回调相关配置结果集合    ScanDynamicModel scanDynamicModel = new ScanDynamicModel();    scanDynamicModel.setDisconfUpdateServiceInverseIndexMap(inverseMap);    //    // set update pipeline，实现iDisconfUpdatePipeline接口的处理    //    if (scanModel.getiDisconfUpdatePipeline() != null) {        IDisconfUpdatePipeline iDisconfUpdatePipeline = getIDisconfUpdatePipelineInstance(scanModel                .getiDisconfUpdatePipeline(), registry);        if (iDisconfUpdatePipeline != null) {            // 存储到scanDynamicModel中            scanDynamicModel.setDisconfUpdatePipeline(iDisconfUpdatePipeline);        }    }    return scanDynamicModel;}
      
     
    

返回以后，会将结果存储到Store仓库中。两种回调方式分别处理。

transformUpdateService(scanDynamicModel.getDisconfUpdateServiceInverseIndexMap());transformPipelineService(scanDynamicModel.getDisconfUpdatePipeline());

private static void transformUpdateService(Map
    
     > disconfUpdateServiceInverseIndexMap) {    // 分别取出配置文件仓库和配置项仓库处理器    DisconfStoreProcessor disconfStoreProcessorFile = DisconfStoreProcessorFactory.getDisconfStoreFileProcessor();    DisconfStoreProcessor disconfStoreProcessorItem = DisconfStoreProcessorFactory.getDisconfStoreItemProcessor();    for (DisconfKey disconfKey : disconfUpdateServiceInverseIndexMap.keySet()) {        try {            if (disconfKey.getDisConfigTypeEnum().equals(DisConfigTypeEnum.FILE)) {                // 如果是文件，第一次静态扫描结束后，肯定会有对应的配置值                if (!disconfStoreProcessorFile.hasThisConf(disconfKey.getKey())) {                    throw new Exception();                }                // 存储到仓库的回调函数属性中                disconfStoreProcessorFile.addUpdateCallbackList(disconfKey.getKey(),                        disconfUpdateServiceInverseIndexMap                                .get(disconfKey));            } else if (disconfKey.getDisConfigTypeEnum().equals(DisConfigTypeEnum.ITEM)) {                // 配置项                if (!disconfStoreProcessorItem.hasThisConf(disconfKey.getKey())) {                    throw new Exception();                }                // 存储到仓库的回调函数属性中                disconfStoreProcessorItem.addUpdateCallbackList(disconfKey.getKey(),                        disconfUpdateServiceInverseIndexMap                                .get(disconfKey));            }        } catch (Exception e) {            // 找不到回调对应的配置，这是用户配置 错误了            StringBuffer sb = new StringBuffer();            sb.append("cannot find " + disconfKey + "for: ");            for (IDisconfUpdate serClass : disconfUpdateServiceInverseIndexMap.get(disconfKey)) {                sb.append(serClass.toString() + "\t");            }            LOGGER.error(sb.toString());        }    }}
    

对于pipeline回调函数类似的处理。

继续第二次扫描。

// 注入数据至配置实体中// 获取数据/注入/Watchif (disconfCoreMgr != null) {    disconfCoreMgr.inject2DisconfInstance();}

该方法的处理，会分别处理File和item两项，分别调用DisconfCoreProcessor实现类（和第一次扫描处理类似）

for (DisconfCoreProcessor disconfCoreProcessor : disconfCoreProcessorList) {    disconfCoreProcessor.inject2Conf();}

下面已File处理为例分析：

inject2Conf()的处理逻辑。

Object object;try {    object = disconfCenterFile.getObject();    if (object == null) {        // 从上下文获取实例        object = registry.getFirstByType(disconfCenterFile.getCls(), false, true);    }} catch (Exception e) {    LOGGER.error(e.toString());    object = null;}// 注入实体中disconfStoreProcessor.inject2Instance(object, fileName);

继续向下看。

@Overridepublic void inject2Instance(Object object, String fileName) {    // 先取出配置存储对象    DisconfCenterFile disconfCenterFile = getInstance().getConfFileMap().get(fileName);    // 校验是否存在    if (disconfCenterFile == null) {        LOGGER.error("cannot find " + fileName + " in store....");        return;    }    //    // 非静态类    //    if (object != null) {        // 设置object        disconfCenterFile.setObject(object);    }    // 根据类型设置值    //    // 注入实体    //    Map
    
      keMap = disconfCenterFile.getKeyMaps();    for (String fileItem : keMap.keySet()) {        // 根据类型设置值        try {            //            // 静态类            //            if (object == null) {                if (keMap.get(fileItem).isStatic()) {                    LOGGER.debug(fileItem + " is a static field. ");                    keMap.get(fileItem).setValue4StaticFileItem(keMap.get(fileItem).getValue());                }                //                // 非静态类                //            } else {                LOGGER.debug(fileItem + " is a non-static field. ");                if (keMap.get(fileItem).getValue() == null) {                    // 如果仓库值为空，则实例 直接使用默认值                    Object defaultValue = keMap.get(fileItem).getFieldDefaultValue(object);                    keMap.get(fileItem).setValue(defaultValue);                } else {                    // 如果仓库里的值为非空，则实例使用仓库里的值                    keMap.get(fileItem).setValue4FileItem(object, keMap.get(fileItem).getValue());                }            }        } catch (Exception e) {            LOGGER.error("inject2Instance fileName " + fileName + " " + e.toString(), e);        }    }}
    

分别对静态和非静态对象属性赋值。

到这里位置第二次扫描结束了。

通过两次扫描加载的数据，都是通过注解式的分布式配置方式，Disconf同时支持XML非注解式配置方式，在上篇介绍的时候，我们留下了关于XML载入的配置处理的分析，下面分析下XML非注解式配置的源码。

对于非注解式配置，Disconf主要区分为properties文件和非properties文件（properties文件才支持自动reload）、是否自动载入reload到bean对象中（通过XML配置决定）。

我们先分析支持自动reload。

    
        
             
                  
       
        classpath:/autoconfig.properties
                   
       
        classpath:/autoconfig2.properties
               
          
     
    
        
         
         
             
                  
               
          
     
    

解读上面的配置前，先了解下Spring提供的PropertyPlaceholderConfigurer类 ，它支持将properties文件中的配置项读取并在XML中通过#{}的方式读取，他的触发是因为实现了BeanFactoryPostProcessor接口，扩展了postProcessBeanFactory方法。

而Disconf就是在此基础上继续扩展，ReloadingPropertyPlaceholderConfigurer继承了PropertyPlaceholderConfigurer类。

首先看下ReloadablePropertiesFactoryBean类，它继承了PropertiesLoaderSupport类，入口是setLocations()方法。

public void setLocations(List
    
      fileNames) {    List
     
       resources = new ArrayList
      
       ();    for (String filename : fileNames) {        // trim        filename = filename.trim();        String realFileName = getFileName(filename);        //        // register to disconf        // 开始扫描，可以参考上文文件和配置项的扫描        //        DisconfMgr.getInstance().reloadableScan(realFileName);        //        // only properties will reload        //        String ext = FilenameUtils.getExtension(filename);        if (ext.equals("properties")) {            PathMatchingResourcePatternResolver pathMatchingResourcePatternResolver =                    new PathMatchingResourcePatternResolver();            try {                Resource[] resourceList = pathMatchingResourcePatternResolver.getResources(filename);                for (Resource resource : resourceList) {                    resources.add(resource);                }            } catch (IOException e) {                e.printStackTrace();            }        }    }    this.locations = resources.toArray(new Resource[resources.size()]);    lastModified = new long[locations.length];    super.setLocations(locations);}
      
     
    

reloadableScan()方法如下：

public synchronized void reloadableScan(String fileName) {    if (!isFirstInit) {        return;    }    if (DisClientConfig.getInstance().ENABLE_DISCONF) {        try {            // 判断是不是忽略同步的文件            if (!DisClientConfig.getInstance().getIgnoreDisconfKeySet().contains(fileName)) {                if (scanMgr != null) {                    // 扫描配置                    scanMgr.reloadableScan(fileName);                }                if (disconfCoreMgr != null) {                    // 核心处理器处理                    disconfCoreMgr.processFile(fileName);                }                LOGGER.debug("disconf reloadable file: {}", fileName);            }        } catch (Exception e) {            LOGGER.error(e.toString(), e);        }    }}

scanMgr.reloadableScan()会执行StaticScannerNonAnnotationFileMgrImpl.scanData2Store();，注意StaticScannerNonAnnotationFileMgrImpl，在上文中，我们介绍了，扫描工具主要包括三种：文件、配置项、非注解配置。在第一次扫描的时候，非注解配置因为list为空（详细看上文），所以没有执行后面的逻辑。

继续看非注解扫描工具处理。

public static void scanData2Store(String fileName) {    // 组装仓库对象，和注解文件的不同在于，文件注解本身就是一个对象，非注解配置是一个配置文件，需要转换为对象。    // 组装的过程，存在disconfCenterFile.setIsTaggedWithNonAnnotationFile(true);设置。    // 在第一次扫描的时候，有提到，如果是非注解的，该属性会覆盖之前注解的仓库对象    DisconfCenterBaseModel disconfCenterBaseModel =                StaticScannerNonAnnotationFileMgrImpl.getDisconfCenterFile(fileName);    // 因为非注解配置肯定文件，所以调用文件仓库处理器，后面的逻辑参考上文    DisconfStoreProcessorFactory.getDisconfStoreFileProcessor().transformScanData(disconfCenterBaseModel);    }

扫描完成以后，开始核心处理器处理。

/** * 只处理某一个 */@Overridepublic void processFile(String fileName) {    // 获取配置文件核心处理器，原理和上文一样    DisconfCoreProcessor disconfCoreProcessorFile =            DisconfCoreProcessorFactory.getDisconfCoreProcessorFile(watchMgr, fetcherMgr, registry);    // 在第一次扫描的时候会调用processAllItems()处理，但是xml配置的扫描肯定是单个的，所以直接调用单个处理    disconfCoreProcessorFile.processOneItem(fileName);}

再后面的处理和第一次扫描的处理是同一个方法，一個配置文件, 下载、注入到仓库、Watch 三步骤。

继续XML配置解析，对于properties类型的文件，Spring的PropertyPlaceholderConfigurer类支持处理，所以最后将properties类型的文件设置到父类的locations属性中。setLocations()结束。

因为ReloadablePropertiesFactoryBean继承自PropertiesFactoryBean，PropertiesFactoryBean实现了InitializingBean接口，所以在初始化的时候，会调用afterPropertiesSet()方法。

public final void afterPropertiesSet() throws IOException {    if(this.singleton) {        this.singletonInstance = this.createProperties();    }}protected Properties createProperties() throws IOException {    return this.mergeProperties();}

而ReloadablePropertiesFactoryBean重载了createProperties()方法。

@Overrideprotected Properties createProperties() throws IOException {    return (Properties) createMyInstance();}/** * @throws IOException */protected Object createMyInstance() throws IOException {    // would like to uninherit from AbstractFactoryBean (but it's final!)    if (!isSingleton()) {        throw new RuntimeException("ReloadablePropertiesFactoryBean only works as singleton");    }    // set listener    reloadableProperties = new ReloadablePropertiesImpl();    if (preListeners != null) {        reloadableProperties.setListeners(preListeners);    }    // reload    reload(true);    // add for monitor    ReloadConfigurationMonitor.addReconfigurableBean((ReconfigurableBean) reloadableProperties);    return reloadableProperties;}

首先看ReloadablePropertiesImpl的实现，他继承自ReloadablePropertiesBase，包含了List<IReloadablePropertiesListener> listeners监听列表。开始preListeners默认为null，直接执行reload(true)，默认情况下reload方法通过判断配置文件的修改时间来确认是否重新加载，这里因为传参为true，所以强制reload()。调用ReloadablePropertiesBase的setProperties()。

/** * 通过listener去通知 reload * * @param oldProperties */protected void notifyPropertiesChanged(Properties oldProperties) {    PropertiesReloadedEvent event = new PropertiesReloadedEvent(this, oldProperties);    for (IReloadablePropertiesListener listener : listeners) {        listener.propertiesReloaded(event);    }}/** * set value 触发 * * @param properties */protected void setProperties(Properties properties) {    Properties oldProperties = internalProperties;    synchronized(this) {        internalProperties = properties;    }    notifyPropertiesChanged(oldProperties);}

可以看到最后会遍历前面所说的listeners列表，如果有值的情况会调用listener的propertiesReloaded()方法去reload。IReloadablePropertiesListener接口的实现类是ReloadingPropertyPlaceholderConfigurer。

有了ReloadablePropertiesFactoryBean以后，Disconf支持两种非注解式处理，分别的Spring自带的PropertyPlaceholderConfigurer和ReloadingPropertyPlaceholderConfigurer。两者的区别是会不会自动reload。结合上面所说，如果想要自动reload，就是通过listeners列表实现。如果使用Spring自带的PropertyPlaceholderConfigurer，那么自然就不会有listener。

当我们使用ReloadingPropertyPlaceholderConfigurer的作为XML配置时，因为实现了InitializingBean接口，所以会执行afterPropertiesSet()。

/** * afterPropertiesSet * 将自己 添加 property listener */public void afterPropertiesSet() {    for (Properties properties : propertiesArray) {        if (properties instanceof ReloadableProperties) {            logger.debug("add property listener: " + properties.toString());            // addReloadablePropertiesListener执行了listeners.add()。            ((ReloadableProperties) properties).addReloadablePropertiesListener(this);        }    }}

在加载ReloadablePropertiesFactoryBean的时候，我们已经把所有的properties格式的文件放入到propertiesArray，所以都会加入到listener中，最后会调用propertiesReloaded()进行处理。

至此，Disconf的启动过程分析结束。

转载请注明出处。

作者：wuxiwei

出处：https://www.cnblogs.com/wxw16/p/10741202.html