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 ]
[
下一页 ]