FileChangedReloadingStrategy什么鬼?

背景：项目中使用了common-configuration库用于加载配置文件，并通过扩展的ConfigManager实现统一的配置管理。

现象：考虑到有些配置信息可以通过热加载的方式，不用重启服务器进行更新。commons-configuration提供了ReloadingStrategy和ConfigurationListener，示例代码如下，通过RELOAD事件做实时的属性更新操作，然而系统跑起来之后，修改文件并未监控到该事件的产生。

PropertiesConfiguration config = new PropertiesConfiguration(configFile); 
FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();        
config.setReloadingStrategy(strategy);
config.addConfigurationListener(new ConfigurationListener() {
          
    @Override
    public void configurationChanged(ConfigurationEvent e)
    {
        System.out.println("配置文件更新..."+e.getType());
        if(PropertiesConfiguration.EVENT_RELOAD ==e.getType())
        {
          System.out.println("配置文件重载...");
        }
    }
});

分析：首先排除apache的弱智，在该段代码后，起一个独立线程，每隔1秒打印一下目标属性的值，看是否成功reload。结果发现不仅成功reload，ConfigurationEvent也产生的，Changed执行了，什么鬼？去掉线程后，又是老样子。网上搜索毫无结果，最后只能到apache官网找原因，并最终找到如下描述： FileChangedReloadingStrategy works as follows: On every property access the configuration checks its associated reloading strategy. 
居然是在属性访问的时候才check？要不访问那listener不就毫无用处？！access的时候重载不还要做并发控制，要加锁，虽然配置文件读一下很快，不也影响体验？

解决方案：
1.X版本只能自己另外创建个线程调用get方法以触发property的access，进而触发configurationChanged。
2.X版本新增了一个PeriodicReloadingTrigger来解决此问题，它会起一个ScheduledExecutorService，通过线程方式来处理

FileChangedReloadingStrategy什么鬼?

原文：http://my.oschina.net/u/699015/blog/478305