在研究规则引擎时，如果规则以文件的形式存储，则需要监视指定的目录或文件，以感知规则是否更改，然后加载。当然，在其他业务场景中，例如动态加载配置文件，日志文件的监视以及FTP文件的更改等，它们将遇到相似的场景。
本文为您提供了三种解决方案，并分析了优势和缺点。建议收集它不时准备。
该解决方案是最简单，最直接的解决方案。通过定时任务，将旋转查询文件的最终修改时间与上次进行比较。如果发生更改，则意味着已修改文件以重新加载或对应于商业逻辑。
在上一篇文章“ JDK的错误，请注意监视文件”，已在特定示例中写成，它还提出了缺点。
在此处发布示例代码：
对于文件中低频变化的场景，该解决方案很简单，并且基本上满足了需求。如上一篇文章所述，您需要注意文件＃lastmodify的错误问题Java 8和Java 9。
但是，如果该方案用于更改文件目录，则缺点有点明显。例如，该操作频繁，效率在遍历，保存状态和对比状态下丢失，并且不能使用OS功能。
在Java 7中新增加，它可以通过IT来监视文件更改。WATCHSERVICE是基于操作系统的文件系统监视器。它可以监视系统的所有文件的更改。它不需要穿越或比较。它是基于信号的监视和高效率。
上面的演示显示了手表服务的基本用途，注释部分还说明了每个API的特定作用。
通过WatchService的侦听文件类型变得更加丰富：
如果您查看WatchService实现类的源代码（PollingWatchService），您会发现它本质上是监视文件更改的独立线程：
换句话说，我们手动实施的一部分也由WatchService完成。
如果您编写演示并验证它，显然会感觉到WatchService监视文件的更改不是真实的。有时，监视文件中的更改需要几秒钟。以PollingWatchService的实现为例。查看源代码，您可以看到以下代码：
换句话说，侦听器由调度程序根据固定时间间隔控制，并且此时间间隔在sexitivityWatchEventModifier类中定义：
该课程分别提供3个级别间隔，2秒，10秒和30秒，默认值为10秒。当路径＃寄存器：寄存器：可以传递此时间间隔：
与计划1相比，实施和高效率很容易。缺陷也很明显。您只能在当前目录中监视文件和目录。我们无法监视子目录。我们还看到，只能实时考虑监视，并且监视时间只能采用API默认值提供的三个值。
API还建议Java 7在堆栈溢出的Mac OS下有一个延迟的问题，甚至涉及Windows和Linux系统。作者不验证其他操作系统。如果遇到类似的问题，则可以参考相应的文章。寻求解决方案：https：//blog.csdn.net/claram/article/article/details/97919664。
我们自己实施该计划。计划2在JDK API的帮助下实施。该方案的第三个是实现开源框架。这是几乎每个项目引入的Commons-io类库。
引入相应的依赖性：
请注意，不同版本需要不同的JDK支持，2.7需要Java 8及以上。
CONSON-IO的实现文件监视的实现位于org.apache.commons.io.monitor下。基本使用过程如下：
步骤1：创建文件监视器。相应的业务逻辑处理是根据需要以不同的方法实现的。
步骤2：润滑文件监视工具类。核心是创建一个观察者filealterationObserver，以封装文件路径和Monitor fileSealterationListener，然后将其交给FilealteitiesMonitor。
步骤3：致电并执行：
如果执行程序，您会发现每1秒输入日志。当文件更改时，将打印相应的日志：
当然，可以通过创建Filemonitor来修改相应的监视时间间隔。
该方案本身将开始及时处理的线程。每次运行的时间，您首先调用事件监视处理类的ONSTART方法，然后检查是否有更改，并调用相应的事件方法；例如，Onchange文件内容更改，在检查了CPU资源之后，等待下次唤醒并再次运行。
侦听器基于文件目录，还可以设置一个过滤器以实现相应文件更改的监视。过滤器的设置以查看FileSealterationObserver的构造函数：
在这一点上，已经引入了基于监视文档的更改Java的三个解决方案。在上述分析和实例之后，每个人都发现没有完美的解决方案。根据他们的业务条件和系统的容忍度，可以选择最合适的解决方案。此外，可以在此基础上添加其他一些辅助措施，以避免特定计划中的缺点。
博客作者简介：“ Springboot Technology Inner Book”技术书籍作者，喜欢学习技术，撰写技术干货文章。
公共帐户：博客作者的公共帐户“计划的新愿景”，欢迎关注?
技术交流：请联系博客微信：Zhuan2quan
原始：https：//juejin.cn/post/7103318602748526628