FileChangedReloadingStrategy什么鬼?

摘要: commons-configuration基于FileChangedReloadingStrategy的配置文件变化重载触发机制，无法自动触发configurationChanged事件

背景：项目中使用了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，通过线程方式来处理