1700484800
1700484801
为什么要在这里定义一个Watchable接口呢？它表示所有可以监视的资源，比如数据库、日志文件、磁盘空间等。我们来看代码，监听接口如代码清单38-8所示。
1700484802
1700484803
代码清单38-8 监听接口
1700484804
1700484805
public interface Watchable{
1700484806
1700484807
//监听
1700484808
1700484809
public void watch（）；
1700484810
1700484811
}
1700484812
1700484813
文件监听者是观察者模式的被观察者，它一旦发现文件发生变化立刻通知观察者，如代码清单38-9所示。
1700484814
1700484815
代码清单38-9 文件监听者
1700484816
1700484817
public class FileWatcher extends Observable implements Watchable{
1700484818
1700484819
//是否要重新加载XML文件
1700484820
1700484821
private boolean isReload=false；
1700484822
1700484823
//启动监视
1700484824
1700484825
public void watch（）{
1700484826
1700484827
//启动一个线程，每隔15秒扫描一下文件，发现文件日期被修改，立刻通知观察者
1700484828
1700484829
super.addObserver（new Checker（））；
1700484830
1700484831
super.setChanged（）；
1700484832
1700484833
super.notifyObservers（isReload）；
1700484834
1700484835
}
1700484836
1700484837
}
1700484838
1700484839
由于框架是在操作系统之上运行的，文件变化时操作系统是不会通知应用系统的，因此我们能做的就是启动一个线程监视一批文件，发现文件改变了，立刻通知相关的处理者，它虽然有时间延迟，但对于一个应用框架来说是非常有必要的，避免了重启应用才能使配置生效的情况。
1700484840
1700484841
读者可能很疑惑，这种死循环的监控方式会不会对性能产生影响，答案是不会！为什么呢？检查一个文件的时间一般是毫秒级的，相对于我们设置的运行周期（比如15秒执行一次）是一个非常微小的运行时间，对应用不会产生任何影响。大家都在使用Log4j进行日志处理，它有一个线程是每5秒检查一次日志是否满，大家觉得性能受影响了吗？基本上性能影响可以忽略不计。
1700484842
1700484843
由于Checker还要作为观察者，因此它要实现Observer接口，同时实现update方法，如代码清单38-10所示。
1700484844
1700484845
代码清单38-10 修正后的检查者
1700484846
1700484847
public class Checker implements Observer{
1700484848
1700484849
public void update（Observable arg0，Object arg1）{
[
上一页 ]
[ :1.7004848e+09 ]
[
下一页 ]